Comments 3
Спасибо за продолжение!
Ведь по большому счету пользователю какого-нибудь сайта глубоко пофиг, соблюдаются ли под капотом этого сайта принципы ООП или нет. Точно так же как разработчику этого сайта плевать, как там устроены внутренности используемого фреймворка.
Разработчик библиотеки может забить на все принципы ООП, если они противоречат главному принципу библиотеки – простоте и интуитивности использования.А разве это же утверждение не справедливо и по отношению к «обычному» прикладному ПО?
Ведь по большому счету пользователю какого-нибудь сайта глубоко пофиг, соблюдаются ли под капотом этого сайта принципы ООП или нет. Точно так же как разработчику этого сайта плевать, как там устроены внутренности используемого фреймворка.
Ну, все не совсем так:)
Конечно, нашим пользователям глубоко плевать на все ООП, ФП и прочий матан; им важно одно: time-to-market, т.е. когда будет сделана нужная функциональность, с какими затратами и качеством. Это наше с вами дело, каким именно образом это обеспечить. И вот тут как раз хорошие практики вступают в силу: хорошо спроектированная система более проста в сопровождении и как раз простотой сопровождения, эффективностью и качеством мы с вами занимаемся.
Теперь, когда мы решаем некоторую задачу мы должны учитывать, насколько наше решение должно быть сопровождаемым (вот это уже важно менеджеру и пользователю). Эта характеристика одна из самых важных аспектов когда мы принимаем решение при разработке приложения, но это далеко не такой важный аспект для библиотеки.
При разработке приложения SRP — очень важный принцип, но он уже на так важен для разработчика бибилотеки, поскольку SRP — это значительно в большей степени тактика реализации и в меньшей степени публичной части классов.
Вот и получается, что нет, эта фраза не применима к прикладному ПО.
Конечно, нашим пользователям глубоко плевать на все ООП, ФП и прочий матан; им важно одно: time-to-market, т.е. когда будет сделана нужная функциональность, с какими затратами и качеством. Это наше с вами дело, каким именно образом это обеспечить. И вот тут как раз хорошие практики вступают в силу: хорошо спроектированная система более проста в сопровождении и как раз простотой сопровождения, эффективностью и качеством мы с вами занимаемся.
Теперь, когда мы решаем некоторую задачу мы должны учитывать, насколько наше решение должно быть сопровождаемым (вот это уже важно менеджеру и пользователю). Эта характеристика одна из самых важных аспектов когда мы принимаем решение при разработке приложения, но это далеко не такой важный аспект для библиотеки.
При разработке приложения SRP — очень важный принцип, но он уже на так важен для разработчика бибилотеки, поскольку SRP — это значительно в большей степени тактика реализации и в меньшей степени публичной части классов.
Вот и получается, что нет, эта фраза не применима к прикладному ПО.
1. Эффективность и сопровождаемость.
Сопровождаемость. И только сопровождаемость. Хорошо было бы, если бы программисты думали о термине «оптимизация», как не о кодировании, а о специальном процессе. Который состоит из шагов: замеры производительности и т.д. Без замеров производительности нет и оптимизации. Если нет замеров, любая оптимизация преждевременная.
Хотя бы исходя из того, что сопровождаемый и простой код легко изменять, а значит он поддается оптимизациям. Непростой нелегко изменять, а значит, будет поздно оптимизировать, когда заранее оптимизированный код в результате замеров покажет тормоза. Это как с одеялом — с большого можно потом сделать меньшее, но не наоборот.
Прямо здесь в примере написаны ужасы: разбухание кода. Разбухание чего? Если был бы код и мы бы уже на поздних этапах занялись как и положено оптимизацией и оказалось ВНЕЗАПНО что приложение ест много памяти, то мы бы, наверное, смотрели, что ее ест. Наиболее слабое звено. Код???? Да я физически не могу написать столько кода, даже если он в 5 раз при компиляции вырастет.
Если вырастет на несколько байт код класса — это не повод расстраиваться. Также как не повод мне расстраиваться, что возможно моя зарплата должна быть выше на 0.00001 копейку, но ее округляют в меньшую сторону.
Если что и ест память, то обычно это данные. Т.е. то, что может копироваться или тянуться из базы. Код не копируется. Код класса, напомню, в дотнете хранится в единственном экземпляре. Копироваться код может для женериков. Но и здесь сомнения, что это важно. Я не думаю, что на ходу буду создавать неорганиченное число типов и создавать жененики в цикле. Или даже не буду в цикле, скорее всего, бегать по метаданным, вытягивать все возможные типы и создавать женерики.
Так что если хотят написать эффективный код, то надо писать сопровождаемый. Если каким-то немыслимым способом окажется потом, что наш маленький класс ведет себя очень плохо, отъедая память, то потом ничего не стоит и заменить эти readonly.
2. Безопасность и эффективность
Безопасность. По тем же причинам.
3. Простота vsуниверсальность.
Простота. Согласен с приведенными аргументами. Да и вообще — программирование задачи должно идти в сторону от больших ограничений к меньшим. Это значит, от простого к сложному. И простота должна отвоевываться на каждом шаге.
4. Библиотеки и удобство использования.
Добавить нечего. Хорошо, что я не пишу библиотеки на продажу.
Сопровождаемость. И только сопровождаемость. Хорошо было бы, если бы программисты думали о термине «оптимизация», как не о кодировании, а о специальном процессе. Который состоит из шагов: замеры производительности и т.д. Без замеров производительности нет и оптимизации. Если нет замеров, любая оптимизация преждевременная.
Хотя бы исходя из того, что сопровождаемый и простой код легко изменять, а значит он поддается оптимизациям. Непростой нелегко изменять, а значит, будет поздно оптимизировать, когда заранее оптимизированный код в результате замеров покажет тормоза. Это как с одеялом — с большого можно потом сделать меньшее, но не наоборот.
Прямо здесь в примере написаны ужасы: разбухание кода. Разбухание чего? Если был бы код и мы бы уже на поздних этапах занялись как и положено оптимизацией и оказалось ВНЕЗАПНО что приложение ест много памяти, то мы бы, наверное, смотрели, что ее ест. Наиболее слабое звено. Код???? Да я физически не могу написать столько кода, даже если он в 5 раз при компиляции вырастет.
Если вырастет на несколько байт код класса — это не повод расстраиваться. Также как не повод мне расстраиваться, что возможно моя зарплата должна быть выше на 0.00001 копейку, но ее округляют в меньшую сторону.
Если что и ест память, то обычно это данные. Т.е. то, что может копироваться или тянуться из базы. Код не копируется. Код класса, напомню, в дотнете хранится в единственном экземпляре. Копироваться код может для женериков. Но и здесь сомнения, что это важно. Я не думаю, что на ходу буду создавать неорганиченное число типов и создавать жененики в цикле. Или даже не буду в цикле, скорее всего, бегать по метаданным, вытягивать все возможные типы и создавать женерики.
Так что если хотят написать эффективный код, то надо писать сопровождаемый. Если каким-то немыслимым способом окажется потом, что наш маленький класс ведет себя очень плохо, отъедая память, то потом ничего не стоит и заменить эти readonly.
2. Безопасность и эффективность
Безопасность. По тем же причинам.
3. Простота vsуниверсальность.
Простота. Согласен с приведенными аргументами. Да и вообще — программирование задачи должно идти в сторону от больших ограничений к меньшим. Это значит, от простого к сложному. И простота должна отвоевываться на каждом шаге.
4. Библиотеки и удобство использования.
Добавить нечего. Хорошо, что я не пишу библиотеки на продажу.
Sign up to leave a comment.
О дизайне. Часть 2. Практические примеры