AgileDays-2011: Отчет Кудрявцева В.Б/Архитектура в Agile

Ссылки сюда (3) →

 Андрей Бибичев.

Презентация

Документ на 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
  • Варианты проверок: предусловия, постусловия, инварианты