Почему во всём мире предприятия, которые делают чипы — жутко прибыльны? Они расширяют производство и строят новые заводы… А «Микрон» за 2020-й год (судя по публикации на cnews):
Операционная прибыль в 2020 г. составила 1,2 млрд руб., прибыль до налогообложения – 25 млн руб., чистый убыток – 470 млн руб.
Помните времена, когда у каждого телефона была своя, только его, зарядка? Разные разъёмы, разные напряжения… Думаю, если вопрос про ремонтопригодность начали всерьёз поднимать — обязательно дожмут через три-пять лет.
Позвольте вставить мои 5 копеек. Тоже некоторое время обходил тему стороной, пока не набрался смелости и не разобрался в данной теме. На мой взгляд, с точки зрения C#:
Ковариантность — позволяет использовать более конкретный (производный) тип, чем указанный. Применима к возвращаемым параметрам. Сохранение иерархии наследования типов, передаваемых в качестве аргументов типа, в обобщенных типах в том же порядке. Так, если класс Cat потомок класса Animal, то список IEnumerable<Cat> потомок списка IEnumerable<Animal>. «Список кошек» — это частный случай «списка животных», в список животных можно занести кошку, а в список кошек занести любое животное (например, собаку) нельзя. Тип (в данном случае обобщённый интерфейс) IEnumerable<T> ковариантен своему параметру-типу T.
Контравариантность — позволяет использовать более универсальный (базовый) тип, чем указанный. Применима к принимаемым параметрам. Обращение иерархии наследования типов, передаваемых в качестве аргументов типа, на противоположную в обобщенных типах. Так, если класс Cat потомок класса Animal, а делегат Action<T> определён как метод, принимающий объект типа T, то Action<Animal> потомок делегата Action<Cat>, а не наоборот. Если «все коты — животные», то «всякий метод (например, сфотографировать), оперирующий животными, может выполнить операцию над котом». Но не наоборот — метод, оперирующий котами (например, подержать в руках), не может выполнить операцию над любым животным (например, слоном). В таком случае говорят, что тип (в данном случае обобщённый делегат) Action<T> контравариантен своему параметру — типу T.
Надеюсь, правильно разобрался. Или — что то не так? Буду благодарен за критику.
за поддержку статьи, которая по сути оффтоп и мало связана с хабром (вернее, вообще никак не связана).
Спасибо, что разъяснили, буду знать. Я тут относительно недавно, потому, не мне судить - оффтоп это или не оффтоп, поверю Вам на слово. Понимаю, не всем интересно, а только тем, кто с подобным (увы) сталкивался.
А нет такого места (типа песочницы) куда можно переносить подобные оффтоп статьи?
М, да… А потом начнут за коммуналку липовые счета присылать.
Мораль — платить надо через личный кабинет. Или, личный кабинет банка. Но, не по ссылке из письма (квитанции)…
dll-ка перестаёт быть кодом в момент, когда её скомпилируют :) У вас нет доступа из проекта к коду библиотеки.
Вообще-то, тут никто никому ничем не обязан. Более того, мне совершенно наплевать, что вы думаете про принципы SOLID. Продолжайте это думать сколько угодно, я не ставил себе целью кого-то переубедить.
Создавая сортировку в C# программисты делали библиотеку, потому предусмотрели — что бы это был универсальный инструмент. Относится ли это как то к SOLID? Вряд ли. Ведь SOLID — он применительно к коду, а не к библиотекам.
Так понимаю, реального примера «из жизни» применения принципа открытости/закрытости не будет.
Удачи ребятам.
P.S. IMHO, главное тут:
Ковариантность — позволяет использовать более конкретный (производный) тип, чем указанный. Применима к возвращаемым параметрам. Сохранение иерархии наследования типов, передаваемых в качестве аргументов типа, в обобщенных типах в том же порядке. Так, если класс Cat потомок класса Animal, то список IEnumerable<Cat> потомок списка IEnumerable<Animal>. «Список кошек» — это частный случай «списка животных», в список животных можно занести кошку, а в список кошек занести любое животное (например, собаку) нельзя. Тип (в данном случае обобщённый интерфейс) IEnumerable<T> ковариантен своему параметру-типу T.
Контравариантность — позволяет использовать более универсальный (базовый) тип, чем указанный. Применима к принимаемым параметрам. Обращение иерархии наследования типов, передаваемых в качестве аргументов типа, на противоположную в обобщенных типах. Так, если класс Cat потомок класса Animal, а делегат Action<T> определён как метод, принимающий объект типа T, то Action<Animal> потомок делегата Action<Cat>, а не наоборот. Если «все коты — животные», то «всякий метод (например, сфотографировать), оперирующий животными, может выполнить операцию над котом». Но не наоборот — метод, оперирующий котами (например, подержать в руках), не может выполнить операцию над любым животным (например, слоном). В таком случае говорят, что тип (в данном случае обобщённый делегат) Action<T> контравариантен своему параметру — типу T.
Надеюсь, правильно разобрался. Или — что то не так? Буду благодарен за критику.
за поддержку статьи, которая по сути оффтоп и мало связана с хабром (вернее, вообще никак не связана).
Спасибо, что разъяснили, буду знать. Я тут относительно недавно, потому, не мне судить - оффтоп это или не оффтоп, поверю Вам на слово. Понимаю, не всем интересно, а только тем, кто с подобным (увы) сталкивался.
А нет такого места (типа песочницы) куда можно переносить подобные оффтоп статьи?
Золотые слова, Юрий Бенедиктович (с) Наша Раша
Эти бы слова — да нашему тимлиду в уши.
Мораль — платить надо через личный кабинет. Или, личный кабинет банка. Но, не по ссылке из письма (квитанции)…
Очень интересно будет почитать.
С уважением.
Удачи вам.
Как говорится, на работе Ж рвут не там, где много платят, а где у начальника большие амбиции.
dll-ка перестаёт быть кодом в момент, когда её скомпилируют :) У вас нет доступа из проекта к коду библиотеки.
Ну, зачем на личности то переходить и грубить?
Так понимаю, реального примера «из жизни» применения принципа открытости/закрытости не будет.