< AgileDays-2011: Отчет Кудрявцева В.Б
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Андрей Бибичев.
- Презентация
- Документ на slideshare.net (Спасибо Диме Белобородову за ссылку)
Хороший доклад про паттерны и антипаттерны ООП. Интересно, однако, что внедрение многих хороших упомянутых практик в RMS (и в ЗИС вообще) началось по инициативе «снизу», а не пришло из TechEvol.
Вполне можно использовать как справочник или мантру для размышления каждый вечер
Общее
- + Side-effects
- + Избыточная область видимости
- + Мутабельность всего и вся
- + Большие глобальные контексты
- God-класс
- Огромные классы, которые умеют «все». Их рост все труднее остановить, так как новую функциональность становится все проще реализовать внутри такого класса и все сложнее вне его.
- Может помочь паттерн State (GoF)
- В RMS пример такого класс — InitialDataTestBase, базовый класс тестов с деревней
- Огромные функции
- Андрей привел пример из Open-Source проекта, функцию длиной 9520 строк
Взаимодействие классов
- Длинные руки объектов = длинные цепочки вызовов по большим графам объектов
Как бороться?
- Inversion of Control (наиболее предпочитаемый метод — через конструктор)
- Law of Demeter
- Принцип «Tell, don’t ask»
- рекомендую посмотреть пример из презентации
Наследование
Способы:
- Общие данные + helper-методы к ним
- чаще всего наследников мало
- не предполагаться написание новых наследников
- сам базовый класс в API никак не фигурирует
- правки наследников рушат базовый
- Расширение функциональности за счет перекрытия виртуальных методов
- Отдельная проблема — когда вызывать базовую реализацию в перекрытом методе, «до» или «после»
- Очень тяжело, если на n+1 уровне нужно что-то изменить
- Наследование как отношение «is»
- Методы добавляют новое поведение
- иногда очень тяжело правильно понять, к какой иерархии отнести класс, цена ошибки очень высока
По возможности, от наследования лучше отказываться:
- Interface over inheritance
- Composition over Inheritance
- Delegation over Inhertance
Что еще
- AOP
- Design by contract
- Хорошо не статическим проверками, а тем, что программист задумывается над тем что пишет
- Инструмент .NET — Microsoft Code Contracts
- Варианты проверок: предусловия, постусловия, инварианты
