https://lib.custis.ru/index.php?action=history&feed=atom&title=AgileDays-2011%3A_%D0%9E%D1%82%D1%87%D0%B5%D1%82_%D0%9A%D1%83%D0%B4%D1%80%D1%8F%D0%B2%D1%86%D0%B5%D0%B2%D0%B0_%D0%92.%D0%91%2F%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0_%D0%B2_Agile 2026-04-11T16:01:26Z История изменений этой страницы в вики MediaWiki 1.26.4 https://lib.custis.ru/index.php?title=AgileDays-2011:_%D0%9E%D1%82%D1%87%D0%B5%D1%82_%D0%9A%D1%83%D0%B4%D1%80%D1%8F%D0%B2%D1%86%D0%B5%D0%B2%D0%B0_%D0%92.%D0%91/%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0_%D0%B2_Agile&diff=26682&oldid=prev 2011-05-10T08:34:48Z

<p>Новая страница: « Андрей Бибичев. ;Презентация: [http://www.slideshare.net/biBIGine/agile-7158754 Документ на slideshare.net (Спасибо Ди...»</p> <p><b>Новая страница</b></p><div> Андрей Бибичев.<br /> <br /> ;Презентация: [http://www.slideshare.net/biBIGine/agile-7158754 Документ на slideshare.net (Спасибо Диме Белобородову за ссылку)]<br /> <br /> Хороший [[Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011)|доклад]] про паттерны и антипаттерны ООП. Интересно, однако, что внедрение многих хороших упомянутых практик в RMS (и в ЗИС вообще) началось по инициативе «снизу», а не пришло из TechEvol.<br /> <br /> Вполне можно использовать как справочник или мантру для размышления каждый вечер<br /> <br /> ==== Общее ====<br /> * Неустойчивый код '''='''<br /> ;'''+''' Side-effects<br /> ;'''+''' Избыточная область видимости<br /> ;'''+''' Мутабельность всего и вся<br /> ;'''+''' Большие глобальные контексты<br /> * God-класс<br /> ** Огромные классы, которые умеют «все». Их рост все труднее остановить, так как новую функциональность становится все проще реализовать внутри такого класса и все сложнее вне его.<br /> ** Может помочь паттерн State (GoF)<br /> ** В RMS пример такого класс — &lt;tt&gt;InitialDataTestBase&lt;/tt&gt;, базовый класс тестов с деревней<br /> * Огромные функции<br /> ** Андрей привел пример из Open-Source проекта, функцию длиной 9520 строк<br /> <br /> ==== Взаимодействие классов ====<br /> * Длинные руки объектов = длинные цепочки вызовов по большим графам объектов<br /> <br /> Как бороться?<br /> * Inversion of Control (наиболее предпочитаемый метод — через конструктор)<br /> * [http://en.wikipedia.org/wiki/Law_of_Demeter Law of Demeter]<br /> * Принцип «Tell, don’t ask»<br /> ** рекомендую посмотреть пример из презентации<br /> <br /> ==== Наследование ====<br /> Способы:<br /> * Общие данные + helper-методы к ним<br /> ** чаще всего наследников мало<br /> ** не предполагаться написание новых наследников<br /> ** сам базовый класс в API никак не фигурирует<br /> ** правки наследников рушат базовый<br /> * Расширение функциональности за счет перекрытия виртуальных методов<br /> ** Отдельная проблема — когда вызывать базовую реализацию в перекрытом методе, «до» или «после»<br /> ** Очень тяжело, если на n+1 уровне нужно что-то изменить<br /> * Наследование как отношение «is»<br /> ** Методы добавляют новое поведение<br /> ** иногда очень тяжело правильно понять, к какой иерархии отнести класс, цена ошибки очень высока<br /> <br /> По возможности, от наследования лучше отказываться:<br /> * Interface over inheritance<br /> * Composition over Inheritance<br /> * Delegation over Inhertance<br /> <br /> ==== Что еще ====<br /> * AOP<br /> * Design by contract<br /> ** Хорошо не статическим проверками, а тем, что программист задумывается над тем что пишет<br /> ** Инструмент .NET — Microsoft Code Contracts<br /> ** Варианты проверок: предусловия, постусловия, инварианты</div>

StasFomin