Комментарии 8
Да уж, «Книга Дракона» прямо-таки образец банальности.
После списка литературы я начал активно ощущать собственную неполноценность.
> прежде чем рекомендовать младшему инженеру книжку про ООП, лучше дать книжку про модульность и абстракцию (например, SICP)
Это Вы хорошо сказали. Еще лучше — не зацикливаться на заветных трех буквах (ООП). Спасибо за интересные «сленговые» названия книг (про мага с Золушкой впервые услышал).
Это Вы хорошо сказали. Еще лучше — не зацикливаться на заветных трех буквах (ООП). Спасибо за интересные «сленговые» названия книг (про мага с Золушкой впервые услышал).
Я считаю немного иначе.
Мне больше представляется модель «вход-выход» (модель черного ящика), если мы говорим про большие приложения со сложной архитектурой.
Это бывает полезно при работе на любых уровнях. Как подход к мышлению.
То есть существуют
— задачи, которые стоят перед какой-либо методологией, подходом, сущностью
— способы решения этих задач
— критерии оценки эффективности этих задач, метрики ПО (см. «Rapid Software Development», Dr. Bob Martin)
К примеру
1. Вход У вас на входе проблема — статическая зависимость одного класса от другого.
2. Выбор способа решения (из нескольких!). Вы выбираете принцип инъекции зависимостей. Берете подходящий паттерн — Strategy. Рефакторите.
3. Смотрите. В итоге получилась инъекция в метод, и первый класс теперь зависит от интерфейса (принимает на вход любую реализую интерфейса), и второй класс также становится зависим от интерфейса, он теперь обязан его реализовывать :)
4. Замеряем, смотрим. Изменилась цикломатическая сложность, связанность уменьшилась, но возросло количество классов и методов :)
Это сильно утрированно. Просто когда вы что-то применяете, вы должны понимать, зачем это делаете, что улучшаете в архитектуре и что ухудшаете. Одно лечит, другое калечит — это воистину так, и балансу посвящен вечный рефакторинг. Несколько god Object — трудно поддерживать, но работает быстро. Миллиард микроклассов — поддерживать легко, но в некоторых языках начинает тормозить. Условно :)
А то просто — «а зачем тебе тут абстрактный класс» — " а лишним не будет, зато красиво",
или там «зачем тут такая высокая связанность между методами? »… невразумительное что-то...". Прямо «а еще я туда ем» (С)
Мне больше представляется модель «вход-выход» (модель черного ящика), если мы говорим про большие приложения со сложной архитектурой.
Это бывает полезно при работе на любых уровнях. Как подход к мышлению.
То есть существуют
— задачи, которые стоят перед какой-либо методологией, подходом, сущностью
— способы решения этих задач
— критерии оценки эффективности этих задач, метрики ПО (см. «Rapid Software Development», Dr. Bob Martin)
К примеру
1. Вход У вас на входе проблема — статическая зависимость одного класса от другого.
2. Выбор способа решения (из нескольких!). Вы выбираете принцип инъекции зависимостей. Берете подходящий паттерн — Strategy. Рефакторите.
3. Смотрите. В итоге получилась инъекция в метод, и первый класс теперь зависит от интерфейса (принимает на вход любую реализую интерфейса), и второй класс также становится зависим от интерфейса, он теперь обязан его реализовывать :)
4. Замеряем, смотрим. Изменилась цикломатическая сложность, связанность уменьшилась, но возросло количество классов и методов :)
Это сильно утрированно. Просто когда вы что-то применяете, вы должны понимать, зачем это делаете, что улучшаете в архитектуре и что ухудшаете. Одно лечит, другое калечит — это воистину так, и балансу посвящен вечный рефакторинг. Несколько god Object — трудно поддерживать, но работает быстро. Миллиард микроклассов — поддерживать легко, но в некоторых языках начинает тормозить. Условно :)
А то просто — «а зачем тебе тут абстрактный класс» — " а лишним не будет, зато красиво",
или там «зачем тут такая высокая связанность между методами? »… невразумительное что-то...". Прямо «а еще я туда ем» (С)
Здесь можно найти хорошо отформатированный PDF (второго издания?) SICP: sicpebook.wordpress.com/.
Кстати, она существует и в русском переводе, довольно качественном, но в мягком переплете.
Кстати, она существует и в русском переводе, довольно качественном, но в мягком переплете.
С англ у меня пока не сложилось, но русский перевод мне не понравился вообще, например в самом начале книги: «Действия, в которых ум проявляет свои способности в отношении своих простых идей, суть главным образом следующие три: 1) Соединение нескольких простых идей в одну сложную; так образовались все сложные идеи». Может дальше лучше, но я попробую читать в англ варианте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Иерархия принципов проектирования, или самые важные слова для инженеров