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

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

Материал из CustisWiki

< AgileDays-2011: Отчет Кудрявцева В.Б
Версия от 11:34, 10 мая 2011; StasFomin (обсуждение | вклад) (Новая страница: « Андрей Бибичев. ;Презентация: [http://www.slideshare.net/biBIGine/agile-7158754 Документ на slideshare.net (Спасибо Ди...»)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск
 Андрей Бибичев.
Презентация
Документ на 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
    • Варианты проверок: предусловия, постусловия, инварианты