Как стать автором
Обновить

Комментарии 9

Пример так себе. Вы делаете тип обобщённым и у вас сразу пропадает возможность использовать арифметические операторы. В новой версии, правда,появились обобщённые статические члены интерфейсов, но в любом случае надо описать ограничение на использование обобщения where.

Но в примере удобнее сразу использовать decimal. А ещё лучше свой класс/структуру денежных сумм, со своим округлением.

Не стоит обобщать все возможные ситуации, часть из которых может и не произойти. Это как преждевременная оптимизация, только ещё хуже и в области архитектуры проекта.

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

Первая ошибка в мотивации (причине) использования обобщений.

generics необходимы в тех случаях, когда мы не можем заранее знать тип данных, который будем использовать.

На самом деле обобщения нужны тогда, когда мы хотим использовать код с множеством типов данных. В основном - для переиспользования логики.

Вторая ошибка в самом примере. Всё же тип обобщения подразумевает контракт - цель его использования. Был бы у вас тип Product<TPrice> - было бы понятно, это тип цены, и это, очевидно, должен быть численный тип.

Ну а дальше можно ещё больше покритиковать пример. Например, продукт сам себя не продаёт. В нормальном мире было бы что-то типа "market.sell(product, buyer);". А если уж надо по разному печатать цену в зависимости от условий, то у продукта был бы метод "ShowPrice()".

Лучше бы вы приводили пример на базе библиотечных типов, заодно бы объяснили, чем хороши обобщения. Например, Dictionary<TKey, TValue> отлично раскрывает тему.

Согласен с комментариями из обоих ваших статей - Вы не особо разбираетесь в том, о чем пишете. Рекомендую набраться опыта, а потом уже писать, если хочется, а не засорять Хабр не то что бесполезными, но даже вредными статьями.

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

Наследование — это худший способ решения любой проблемы. Впрочем, конечно, для ещё не освоивших ООП лучше пользоваться им, так как невозможно научиться не пользоваться наследованием, не умея им пользоваться.

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

ФП может быть даже сложнее, чем ООП, если ещё не знаком с ним.
Тем более что C# как ФП язык достаточно слаб. Для этого есть F#

Пример очень слабенький. Кроме этого, деньги нельзя считать в double и float.

Так себе пример. Деньги лучше инкапсулировать в value object. Расчёты с деньгами вполне нетривиальная штука с 100500 нюансами. Дженнреки или шаблоны, нужны в основном для алгоритмов и структур данных. Если их применять к чему то другому, получится извращение как описано в статье. Пример натягивания совы, на глобус.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории