Персональные инструменты
 

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

Материал из CustisWiki

Перейти к: навигация, поиск
 Андрей Бибичев.
Презентация
Документ на 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
    • Варианты проверок: предусловия, постусловия, инварианты