А потом всплывает баг
-----
И обрабатывается в том же режиме. Все вполне нормально получается.

Да не этот детский баг, который в нормальном режиме обрабатывается. А тот, ради которого держат на складе запас клав и мониторов для оперативной замены.

1. Постановщик задачи. Не может / не хочет принимать решения. Описывает задачи максимально обтекаемо.

------

Как вариант - описывает на уровне своего знания/понимания задачи.

Это всегда так. Описывать не на "уровне своего знания" могут не только лишь все, мало кто может это делать. (ц)

Что делает адекватный постановщик задач, когда возникает технический вопрос, на который он не может ответить? Говорит это. Ротом. Мол, ребята, я не знаю что на это ответить. И или

а. просит предложить решения, которые видят разработчики, описать плюсы и минусы и на основании этого всё же принимает решение "давайте сделаем А".

б. говорит что проконсультируется с архитектором / ПО / знакомым который такое уже делал такое и на следующее обсуждение придёт с ответом (пригласит специалиста, и он даст ответ).

Для такого надо хотеть брать на себя ответственность и принимать решения. Минимум 2/3 этого делать не хотят, и формулируют требования специально размытыми. Чтобы можно было любой косяк спихнуть на разработчиков. Есть разработчики, которым тоже нравятся размытые требования. Потому что можно нахреновертить что угодно, оправдывая это "а так в требованиях написано".

Говорит это. Ротом.

-----

Я думал что опытный всегда писает. На хардкопи...

Это всегда так.

------

Пыхх...

Инструкция по применению Ложки Столовой...

Пишется на том уровне который требуется исполнителю для выполнения задания.

Далеко не всегда это уровень его понимания задачи .

проконсультируется с архитектором

------

А толку?

Описанная выше ситуация - она не выдуманная.

Кодеров завязали на постановщика, постановщика - на контактное лицо, а лицо контактировало с никем у заказчика.

Нормальный "испорченный телефон"

Пока не ознакомили кодеров с предметной областью - ничего не двигалось...

Кто-нибудь может объяснить, зачем делать такое объявление класса

class A<T> where T : B, new()

{

public T MyProperty

}

если можно сделать сразу свойство типа B

class A

{

public B MyProperty

}

Только для того, чтобы потребовать, чтобы у типа B был конструктор без параметров?

Это как написать

class A<T1, T2, T3>

where T1 : Int32

where T2 : String

where T3 : String

{

public T1 Age

public T2 Name

public T3 Surname

}

Круто же!

Это только цветочки. А если ягодки добавить, то становишься сразу незаменимым - хрен кто разберётся. И обфускатор не нужен. Комментов ко всему этому - что и зачем - тоже нет, кстати.

Только для того, чтобы потребовать, чтобы у типа B был конструктор без параметров?

А этого мало? :)

если можно сделать сразу свойство типа B

А в дополнение типа С, Д, Е. Вопрос был бы а нужны ли мне в данной реализации "генерики"?

Только для того, чтобы потребовать, чтобы у типа B был конструктор без параметров?

А этого мало? :)

Это слишком много. Настолько, что можно обойтись и без этого.

А в дополнение типа С, Д, Е. Вопрос был бы а нужны ли мне в данной реализации "генерики"?

Если ему нужен конструктор без параметров, значит он создаёт экземпляр объекта через этот конструктор. Если такого конструктора нет - при компиляции появится ошибка на месте попытки создания объекта, и придётся идти и делать конструктор без параметров для нужного типа. Но она же появится и если написать как он - через дженерик. Но через дженерик более запутанно.

class A where T : B, new(){public T MyProperty}

"В" это обычно или интефейс или абстрактный класс. Подставляя вместо "Т" унаследованные классы от "В" при создании обьекта от класса "А", можно реализовать различный функционал.

Такая структура используется для инкапсуляции, но обычно обьявляют приватным обьектом. .

Это слишком много. Настолько, что можно обойтись и без этого.

Ну если добавили такое ограничение, значит оно для чего-то нужно :) Например где-то в недрах этого класса создается объект типа B, не важно десериализацией или Activator'ом.

Ну если добавили такое ограничение, значит оно для чего-то нужно :) Например где-то в недрах этого класса создается объект типа B, не важно десериализацией или Activator'ом.

Как я написал, что если не ставить такое ограничение для параметра типа, то ошибка компиляции возникнет при попытке создания такого объекта внутри этого класса, если конструктора без параметров нет. А если ставить такое ограничение - то при попытке создать экземпляр этого класса с конкретным типом в качестве параметра типа. Т.е. в любом случае ошибка возникнет при компиляции - т.е. при написании кода, т.к. у нас компилятор на лету это проверяет. Но вариант с ограничениями параметров типов более запутанный.

Вот ещё один "подарок". В базе данных стоит ограничение на поле nvarchar(40). Где-то в глубине бизнес логики при логировании проверяется длина поля на 40 символов (захардкодено числом), и если больше - обрезается. Я так понимаю, что где-то эта строка может оказаться и больше 40 символов. Почему ещё при её создании она не валидируется на длину? А если в обрезанной части важная инфа? А нельзя было сделать так, чтобы эти ограничения на длину где-то в одном месте сидели и оттуда брались, а не были разбросаны захардкоденным способом по всем частям проекта?

Блин, да там дохрена таких полей. Кусок с логированием - магические чиселки без комментов 40, 12, 36 и т.д. Нумерология! Пока в БД не заглянешь в эти поля, не поймёшь, что это такое. Чел, который писал логирование, похоже тупо со схемы БД руками копировал и никак не обозначил, что они означают.

Как я написал, что если не ставить такое ограничение для параметра типа, то ошибка компиляции возникнет при попытке создания такого объекта внутри этого класса, если конструктора без параметров нет.

Нет, ошибки на этапе компиляции не будет. Исключение будет в рантайм.

Можешь проверить:

    public class TestType
    {
        public int Val { get; private set; }
        public TestType(int val)
        {
            Val = val;
        }
    }

...

Activator.CreateInstance(typeof(TestType));

Это подходит только для Активатора и других подобных способов создания объектов в процессе выполнения программы? Т.е. если я работую "обычным" способом - создаю объекты не через динамические механизмы, то всё это мне не нужно?

Вот тут челы из XML их создают (в моём проекте тоже этим балуются). Правда, непонятно, почему не использовать банальную сериализацию? Т.е. они откуда-то получают описание типа в XML, но доступа к C# коду описания этого типа не имеют? Супер-секретность, или раздолбайство с невозможностью пошарить библиотеки с описанием типов?

А вот тут чел пишет, что если нет доступа к приватным конструкторам, то Активатор позволяет его заиметь. Зачем тогда вся эта инкапсуляция, если я могу её легко обойти?

Это подходит только для Активатора и других подобных способов создания объектов в процессе выполнения программы?

Я с ходу вспомню только 3 способа динамического создания объектов: активатор, взять конструктор через рефлершен (по сути тот же активатор) и десериализация. Во всех 3-х случаях ошибка не будет поймана на стадии компилирования.

Т.е. если я работую "обычным" способом - создаю объекты не через динамические механизмы, то всё это мне не нужно?

Совершенно верно.

Правда, непонятно, почему не использовать банальную сериализацию? Т.е. они откуда-то получают описание типа в XML, но доступа к C# коду описания этого типа не имеют? Супер-секретность, или раздолбайство с невозможностью пошарить библиотеки с описанием типов?

Может быть несколько причин для ручного чтения. Например, использования аттрибута KnownTypeAttribute добавляет в XML вспомогательные метаданные, которые по каким-то причинам нежелательны.

Зачем тогда вся эта инкапсуляция, если я могу её легко обойти?

Перед тем как выстрелить себе в колено нужно изучить все детали :)

В чём прикол делать приватный словарь, а потом публичные методы доступа к нему GetValue и SetValue, которые просто достают данные из словаря и помещают их в него?

Ещё такой подарок. В одном месте данное называется FileName. Потом оно передаётся в другое место, и там оно уже - FormName. Далее в третьем месте присваивается - уже SessionState (не спрашивайте про логику названия). Чтобы понять, что состояние сессии в поле таблицы в БД - это на самом деле имя файла формы в проекте - надо перелопатить кучу кода и отследить кучу присваиваний.

Или вот циклическое владение друг другом. Форма имеет ссылку на сессию, а сессия - на форму. Связь 1 к 1. Нахрена?!

И до кучи - специально выделенные строковые поля для имени формы в объекте сессии, и для состояния сессии в объекте формы. С учётом вышесказаного...

Или вот у нас в классе формы, которая хранит состояние сессии, ещё добавлен объект транзакции в БД. А объекту транзакции в БД передаётся состояние сессии, которое имеет ссылку на форму. Короче, эти три типа - транзакция, сессия, форма - связаны друг с другом и имеют ссылки друг на друга. А теперь нужно разделить эту байду и перенести на другой GUI. Конечно, всё не просто так - там ещё кучка базовых классов добавлена для каждого типа, интерфейсики на каждый тип - всё по фен-шую. Естественно, ссылки друг на друга тоже заложены ещё на этапе базовых классов и интерфейсов. Правда, процентов 90 этих интерфейсов имеют единственную реализацию. Ну и требование конструктора без параметров для динамического создания типов, и всё такое.

Как можно в одном месте сделать по фен-шую, а в другом - самые гразные и разнузданные антипаттерны применять?