http://sergeyteplyakov.blogspot.ru/2013/11/blog-post.html
Цитата:
"Лакмусовая бумажка архитектурного решения
Цитата:
"Лакмусовая бумажка архитектурного решения
Я неоднократно писал о лакмусовой бумажке хорошего дизайна. Когда я рассматриваю дизайн класса или модуля, то стараюсь понять насколько он является цельным и слабосвязным (все те же low coupling и high cohesion) с помощью юнит-тестов. Если их написать невозможно или они будут невменяемыми, то это говорит мне, что с дизайном что-то не то.
А как определить качество архитектурного решения? Чтобы понять, как далеко некоторое решение проникло (или проникнет) в разные части системы, я задаю себе такой вопрос: «А что если я ошибся и мне придется изменить это решение в будущем? Какие будут последствия?». Если некоторое решение размазано ровным слоем по всему приложению, то стоимость его изменения будет огромной, а значит это решение является архитектурным."
Статья годная, о чём я отписался здесь https://plus.google.com/100903871335644471614/posts/BCz2Q92ZkRx
ОтветитьУдалитьСпасибо за ссылку.
Но для меня, наиболее близким в ней было следующее:
«ПРИМЕЧАНИЕ
Дизайн – это постоянный поиск компромиссов. Если мы добавляем гибкость, то мы жертвуем чем-то другим – обычно стоимостью разработки и сопровождения. Аналогично тому, как нет особого смысла заниматься тюнингом производительности приложения на ранних стадиях, нет особого смысла закладывать чрезмерную гибкость каждого разрабатываемого компонента. Именно из-за своих накладных расходов на разработку и сопровождение, оптимизация производительности или гибкости должны производиться лишь тогда, когда мы четко знаем, что это действительно окупится!
Обычно именно простота (помните о разнице между simple и easy ) является наиболее оптимальным фундаментом для будущего улучшения эффективности или изменения функционала.
Мое сдержанное отношение к аспект-ориентированному программированию заключается в том, что у нас уже есть приличное количество хороших техник для выделения аспектов в приложении, которые мы не используем. Я не думаю, что мы решим реальную проблему путем использования более продвинутых техник разделения ответственностей. Мы просто не знаем, какие аспекты нужно выделять и не знаем, когда вообще стоит их выделять, а когда нет.
ПРИМЕЧАНИЕ
Аналогично тому, как Мартин Фаулер сдержано относится к AOP, я сдержано отношусь к IoC-контейнерам. Ведь в нашем арсенале есть огромное количество принципов борьбы со сложностью и обеспечения гибкости: неизменяемость и композиция помогает бороться со сложностью, а многие паттерны проектирования упрощают изменения определенных аспектов системы. Чрезмерное выделение интерфейсов (вначале выделим, а потом посмотрим, нужно ли это) делают систему гибкой и слабосвязной ценой увеличения сложности.
Не делайте систему гибкой на всякий случай, делайте ее гибкой там, где это вам действительно необходимо.»
-- у меня сдержанное отношение и к АОП и к IoC, хотя в той или иной степени/форме находят применение оба подхода. Хотя здесь уместнее говорить даже не о подходах, а о концепциях.
Смешно кстати. Я раз 10-15 перечитывал FAQ Теплякова про C++11. И Всё время им ВОСХИЩАЛСЯ!!!
ОтветитьУдалитьНо при этом его блог я "только что заметил".. :-(