М, да… А потом начнут за коммуналку липовые счета присылать.
Мораль — платить надо через личный кабинет. Или, личный кабинет банка. Но, не по ссылке из письма (квитанции)…
dll-ка перестаёт быть кодом в момент, когда её скомпилируют :) У вас нет доступа из проекта к коду библиотеки.
Вообще-то, тут никто никому ничем не обязан. Более того, мне совершенно наплевать, что вы думаете про принципы SOLID. Продолжайте это думать сколько угодно, я не ставил себе целью кого-то переубедить.
Создавая сортировку в C# программисты делали библиотеку, потому предусмотрели — что бы это был универсальный инструмент. Относится ли это как то к SOLID? Вряд ли. Ведь SOLID — он применительно к коду, а не к библиотекам.
Так понимаю, реального примера «из жизни» применения принципа открытости/закрытости не будет.
Я обычно привожу простой пример, что такое open close — сортировка.
IMHO, плохой пример. Непосредственно в C# уже встроена сортировка. И, в СУБД уже встроена сортировка. Вам не хватает возможностей механизмов сортировки, уже встроенных в C#? Или, вы думаете, что напишите механизм сортитировки лучше, чем это сделали профи из MS? Часто вам приходится писать механизм сортитровки?
Пример должен быть примером. Есть другой пример? Какой нибудь из жизни?
Плотность упаковки транзисторов на кристалл это MTr/mm2? Тогда, согласно таблице, 10-ти нм процесс Intel содержит транзисторов на мм больше, чем 7-ми нм процессы от TSMC и Samsung. Ни чего не понимаю, что же тогда это за «магическая» цифра — ТЕХПРОЦЕСС.
Дело не в программировании, а в обучении впринципе.
Не… Дело не в обучении, а в ОБУЧАЕМОСТИ. У каждого есть свой потолок, выше которого его не обучить, как ни старайся. Не каждый сможет освоить программирование. IMHO, количество людей не земле, которые могут стать программистами меньше, чем количество людей, которые могут стать бухгалтерами, но больше, чем количество людей, которые могут стать хирургами.
Верно подмечено. Ведь по сути, это попытка написания кода, не который требуется для работы в текущий момент, это написание кода, который может потребоваться когда то в будущем. Как показала практика, попытки написания кода «на будущее» приводят к тому, что до будущего обычно не доживают, и часто этот код потом просто удаляется (либо, что хуже, он на всегда остаётся в проекте).
К тому же, написание подобных «закладок на будущее» усложняет код. IMHO, лучше написать простой и понятный с первого прочтения не универсальный код, который при необходимости всегда можно изменить/усложнить добавив универсальности.
А что вы ожидаете? Многие вполне авторитетные ИТ специалисты считают что в скрытности ничего плохого нет и это только и всего еще один слой безопасности. И это так во всем мире, совсем не только в России.
Пожалуйста, не наводите тень на плетень. Как уже доказано, скрытие [алгоритмов] наоборот — отрицательно влияет на безопасность.
Мораль — платить надо через личный кабинет. Или, личный кабинет банка. Но, не по ссылке из письма (квитанции)…
Очень интересно будет почитать.
С уважением.
Удачи вам.
Как говорится, на работе Ж рвут не там, где много платят, а где у начальника большие амбиции.
dll-ка перестаёт быть кодом в момент, когда её скомпилируют :) У вас нет доступа из проекта к коду библиотеки.
Ну, зачем на личности то переходить и грубить?
Так понимаю, реального примера «из жизни» применения принципа открытости/закрытости не будет.
IMHO, плохой пример. Непосредственно в C# уже встроена сортировка. И, в СУБД уже встроена сортировка. Вам не хватает возможностей механизмов сортировки, уже встроенных в C#? Или, вы думаете, что напишите механизм сортитировки лучше, чем это сделали профи из MS? Часто вам приходится писать механизм сортитровки?
Пример должен быть примером. Есть другой пример? Какой нибудь из жизни?
Как же избавиться от Entity Service в случае интернет магазина?
Не… Дело не в обучении, а в ОБУЧАЕМОСТИ. У каждого есть свой потолок, выше которого его не обучить, как ни старайся. Не каждый сможет освоить программирование. IMHO, количество людей не земле, которые могут стать программистами меньше, чем количество людей, которые могут стать бухгалтерами, но больше, чем количество людей, которые могут стать хирургами.
А разве API — это не код? И, через пару лет эксплуатации выясняется, что плагин как был один, так один и остался, и других уже не предвидится?
Верно подмечено. Ведь по сути, это попытка написания кода, не который требуется для работы в текущий момент, это написание кода, который может потребоваться когда то в будущем. Как показала практика, попытки написания кода «на будущее» приводят к тому, что до будущего обычно не доживают, и часто этот код потом просто удаляется (либо, что хуже, он на всегда остаётся в проекте).
К тому же, написание подобных «закладок на будущее» усложняет код. IMHO, лучше написать простой и понятный с первого прочтения не универсальный код, который при необходимости всегда можно изменить/усложнить добавив универсальности.
Пожалуйста, не наводите тень на плетень. Как уже доказано, скрытие [алгоритмов] наоборот — отрицательно влияет на безопасность.