Принципы ООП проектирования
Лучшим материалом на эту тему считаю книгу Роберта Мартина "Быстрая разработка программ. Принципы, примеры, практика". На мой взгляд - это самая важная тема, которой должен овладеть каждый разработчик.
Принцип персональной ответственности
Принцип открытия-закрытия
Принцип подстановки Лискоу
Принцип инверсии зависимостей
Принцип отделения интерфейса
Принцип персональной ответственности (SRP)
Существует лишь одна причина, приводящая к изменению класса. Если существует несколько мотивов для изменения класса, ему соотвествует более одной ответственности.
Ось изменения является таковой лишь в том случае, если изменения действительно происходят. Применять принцип SRP следует только в том случае, когда это оправдано.
Читать далее »
Метрики ООП проектирования
Самая популярная статья на протяжении жизни блога - Принципы ООП проектирования
Также выложено недавно продолжение темы Принципы упаковки программных проектов , которая по идее также должна стать "хитом этого блога". Приятно - когда-то они стали откровением и для меня. И вся книга Роберта К. Мартина со товарищи. Кто из программистов ее еще не прочитал посмотрите на содержание - думаю что оно должно убедить. Поэтому буду и дальше пытаться развивать тему ... если конечно окончательно не свихнусь на BPMS.
Итак первая тема просто обязана была иметь продолжение. И это продолжение - обеспечение контроля соблюдения принципов проектирования - метрики. Конкретно про ООП метрики можно почитать у г-на Романова В.Ю. По метрикам Мартина там также есть информация - так что особого смысла повторять ее здесь нету (все-таки продублировал часть Принципы упаковки программных проектов).
Я программировал на Borland Delphi, когда сам читал Мартина, и сокрушался, что нет средств, которые бы смогли автоматически проверить принципиально важные аспекты моего кода. Тогда "продвинутым" инструментом был JDepend (на сайте можно почерпнуть массу полезной информации, правда на английском) и аналог для .Net NDepend, а для Delphi аналогов небыло.
Потом был случайно найден на SourceForge Delphi Code Analyzer и даже была идея написать для него GUI с пояснениями, но так и провалилась. Ну и в процессе появился Borland Together, который также считает массу метрик... Но кто этим пользуется и кто вообще над этим задумывался?!
P.S.
Вот так ищешь ищешь нормальное решение для Delphi, а оно есть под Java ему уже триста лет в обед. Маленькое и бесплатное. Появляется наконец у Borland и уже стоит 3000 у.е. .., и мало кто им пользуется.
Также недавно где не помню укачал глобальную книгу по метрикам в разработке ПО:
Metrics and Models in Software Quality Engineering, Second Edition
By Stephen H. Kan
Publisher : Addison Wesley
Pub Date : September 20, 2002
ISBN : 0-201-72915-6
Pages : 560
Тут и
- современные модели процессов
- фундаментальная теория измерения
- метрики качества, модели качества
- базовые инструменты качества в разработке ПО
- эффективное устранение дефектов
- метрики тестирования
- метрики и уроки в ООП
- измерение удовлетворения пользователя
- функциональные точки
... и много чего еще.
Жаль нет такой на русском языке
Принципы упаковки программных проектов
В продолжении темы Принципы ООП проектирования хочется продолжить принципами упаковки программных проектов. Взято из Роберт К. Мартин "Быстрая разработка программ. Принципы, примеры, практика".
По мере того, как возрастают размеры и сложность программных проектов, требуется их некоторая высокоуровневая организация. Существует шесть принципов, имеющих к отношение к работе с пакетами. Первые три имеют отношение к сцеплению пакетов. Их применение облегчает выделение классов в пакеты. Остальные три принципа управляют связыванием пакетов. Последние два принципа также описывают набор метрик управления зависимостями. Эти характеристики позволяют разработчикам измерять и характеризовать структуру зависимостей, которая наблюдается в их проектах.
Степень детализации: принципы сцепления пакетов
Принцип эквивалентности повторно применяемых выпусков (REP, Reuse-Release Equivalence Principle)
Уровень детализации повторного применения соотвествует уровню детализации выпуска.
Либо все классы, входящие в состав пакета, являются повторно используемыми, либо ни один из них не входит в эту категорию.
Принцип общего повторного использования (CPR, Common-Reuse Principle)
Классы, входящие в состав пакета, могут повторно использоваться совместно. Если вы можете повторно использовать один из классов, входящих в состав пакета, вам доступны все остальные классы. Совместно используемые классы принадлежат одному пакету, и классы, которые не являются тесно связанными, не относятся к одному пакету.
Принцип общего закрытия (CCP, Common-Closure Principle)
Классы, входящие в состав пакета, должны быть закрыты по отношению к одним и тем же изменениям. Изменение, влияющее на пакет, оказывает воздействие на все классы, входящие в этот пакет (не затрагивая другие пакеты).
Принцип персональной ответственности распространенный на пакеты. Для изменения пакета не должно быть нескольких причин.
Устойчивость: принципы связывания пакетов
Принцип ацикличных зависимостей (ADP, Acyclic-Depending Principle)
Не допускается наличие циклов в графе, описывающем зависимости пакета. Структура пакета «безразлична» к присутствию изменяющихся требований. Естественно, что, по мере поста объема приложений, структура зависимостей пакета «разбухает» и испытывает флуктуации. Именно поэтому структуру зависимостей следует отслеживать на предмет возможного наличия циклов.
Принцип устойчивых зависимостей (SDP, Stable-Dependencies Principle)
Зависит от направления стабильности. Изменчивые пакеты не должны зависеть от пакетов, изменения которых сопряжено со значительными трудностями.
Метрики устойчивости
Один из методов предусматривает подсчет количества зависимостей, которые входят выходят из пакета. Полученные таким образом данные позволяют говорить об оценках позиционной устойчивости пакета.
● (Ca) центростремительное связывание: количество классов вне пакета, которые зависят от классов, образующих пакет.
● (Ce) центробежное связывание: количество классов внутри пакета, которые зависят от классов, не входящих в пакет.
● (I неустойчивость) I = Ce / (Ca + Ce)
Значение метрики попадает в диапазон [0,1]. показатель I = 0 свидетельствует о максимально устойчивом пакете. Показатель I = 1 присущ максимально неустойчивому пакету.
Метрики Ca и Ce определяются путем подсчета количества классов вне данного пакета, которые имею зависимости в классах внутри рассматриваемого пакета. Некоторые программные системы не должны изменяться слишком часто. Эти программы представляют высокоуровневую архитектуру и дизайнерские решения.
Вряд ли мы захотим, чтобы архитектурные решения были изменчивыми. Поэтому программы, представляющие высокоуровневый дизайн системы, должны помещаться в устойчивые пакеты. Неустойчивые пакеты должны включать только те программы, которые должны легко изменяться.
Принцип устойчивости абстракций (SAP, Stable-Abstractions Principle)
Пакет должен быть абстрактным в той же степени, в какой он является устойчивым.
Благодаря применению этого принципа устанавливается взаимосвязь между устойчивостью и абстрактностью. Устойчивые пакеты должны быть также абстрактными, а присущая им устойчивость не предотвращает их возможное расширение. Неустойчивые же пакеты должны быть конкретными.
Оценки абстракций
A-метрика применяется для измерения «степени абстрактности» пакета. Ее значение расчитывается как отношение количества абстрактных классов в пакете к общему количеству классов в пакете.
Nc – количество классов в пакете.
Na – количество абстрактных классов в пакете.
A – мера абстрактности
A = Na / Nc
A-метрика изменяется в диапазоне от 0 до 1. Нулевой показатель означает, что пакет не включает абстрактные классы. Значение равное 1, свидетельствует о том, что пакет состоит исключительно из абстрактных классов.
Главная последовательность
Определим взаимосвязь между устойчивостью (I) и абстрактностью (A). Для этого нарисуем диаграмму, где A представляет ось ординат (по вертикали), а I – ось абсцисс. Если нанести два вида «хороших» пакетов на диаграмму, замечаем, что максимально абстрактные и устойчивые пакеты находятся в верхнем углу (0,1).
Пакеты обладающие максимальной степенью нестабильности и конкурентности, находятся в правом нижнем углу (1,0).
Естественно, что не все пакеты попадают в описанные две категории. Поскольку мы не можем добиться того, чтобы все пакеты попадали в точки с координатами (0,1) и (1,0), остается полагать, что существует область, занимаемая точками на диаграмме A/I, определяющая приемлемые позиции для размещения пакетов. Можно предположить, что эта область определяется зонами, в которых не допускается размещение пакетов.
Рассмотрим пакеты, которые попадают в область с координатами (0,0). Им присуща высокая степень устойчивости и конкретности. И далеко не всегда их применение оправдано из-за присущей им закрепощенности. Причем пакеты не могут расширяться, поскольку не являются абстрактными. А их изменение затруднено в силу характерной для них устойчивости. Поэтому в точке с координатами (0,0) не следует ожидать хорошо спроектированные пакеты.
Болевая зона
Бывают такие ситуации, когда пакеты неизбежно попадают в болевую зону. Например схема БД. Именно схемам БД присуща печально известная изменчивость, беспредельная конкретность, а также высокая степень зависимости. В силу этого реализация интерфейса между OO приложениями и БД является столь непростой, а обновление схем БД затруднены.
Рассмотрим пакет, находящийся в районе точки с координатами (1,1). Эта область нежелательна, поскольку пакету будет присуща максимальная степень абстрактности, причем отсутствуют зависимые от него пакеты. Пользы от подобных пакетов очень мало.
Зона бесполезности
Очевидно, что требуемые нам изменчивые пакеты следует размещать как можно дальше от обеих зон исключения. Область максимального удаления представляет собой прямую, которая соединяет точки (1,0) и (0,1) Хорошие характеристики присущи пакетам, которые находятся либо на главной последовательности, либо возле нее.
Оценка расстояния до главной последовательности
Поскольку желательно, чтобы пакеты находились в области главной последовательности, следует создать метрику, которая измеряет «расстояние от идеала»
D – расстояние
D = |A + I – 1| / sqrt(2)
диапазон изменения находится в области [0,~0,707]
D1 нормализованное расстояние
D1 = |A + I – 1|
Для каждого пакета можно вычислить метрику D. Любой пакет, значение для которого не приближается к нулю, может быть повторно проверен и реструктуризован.
Предостережение
Метрика, описанная здесь, измеряет соответствие проекта "хорошим" образцам зависимости и абстракции. Опыт показал, что некоторые зависимости являются хорошими, а другие плохими. Приведенные образцы отражают тот опыт. Однако, метрика - не бог, а просто измерение на соответствие некоторому стандарту. Для некоторых приложений стандарт будет хорош, для других плох.
Возможно, что имеются лучшие метрики, которые могут использоваться для измерения качества проекта. Таким образом, не стоит решать, что все проекты должны соответствовать метрикам Мартина. Проектировщики должны экспериментировать с этими метриками на своих проектах и оценить их.
Повторное использование кода
Хотелось бы представить еще немного объектной математики. Надеюсь вы обратили внимание и на Мартина и на Лармана особенно на размышления по поводу робастности кода
В начале своей карьеры программиста объектно-ориентированных систем автор пытался создавать максимально обобщенный код и тратил много времени на создание суперклассов для действительно нужных ему классов. Он стремился добиться максимальной общности кода и его гибкости в расчете на последующие изменения, которые так никогда и не понадобились.
Неопытные разработчики зачастую тяготеют к неробастным проектным решениям, более опытные уделяют слишком большое внимание гибкости системы и стремятся к обобщениям (даже если они никогда не понадобятся). Самые опытные специалисты выбирают промежуточное решение, тщательно оценивая вероятность возможных модификаций и усилия, необходимые для обеспечения робастного решения.
Об этом предупреждают везде и Кеннет Бек с Фаулером - принцип "Вам это не понадобится". Есть несколько цифр по COCOMO II
Барри Боэм сделал вывод, что решение о повторном использовании программ может иметь различные следствия. Время, затраченное на поиск подходящих для повторного использования компонент и уяснение принципов их работы, может оказывать отрицательное влияние на выполнение установленного графика разработки. Если принято решение о использовании существующего кода, это всегда будет связано с определенными затратами, даже если на практике осуществить это не удастся. ООП, новейшие IDE, средства документирования - все это может сократить время анализа пригодности ПО для повторного использования, однако никогда не позволить уменьшить его до нуля. Итак предлагаемая Боэмом
Формула оценки влияния повторного использования
ASLOC - количество строк адаптируемого программного текста.
DM - процентное соотношение адаптируемой части к общему объему проекта.
CM - процентное соотношение адаптируемой части к общему объему программ.
IM - процент изменения трудозатрат на интеграцию проекта ( по отношению к планируемым затратам на интеграцию без учета повторного использования)
SU - фактор "понятности программ", определяемый на основе общеупотребительных понятий, подобных четкости структуры приложения, самоописательности его элементов. Дополнительные затраты на работу с повторно используемым программным текстом. Чем проще текст, тем меньше затраты.
AM - фактор "оценки и ассимиляции", характеризующий степень исходной пригодности повторно используемого программного кода для этих целей.
UNFM - показатель, учитывающий, насколько знаком программисту адаптируемый им текст.
Выполняется следующая процедура - Вычисление экономии средств за счет повторного использования программ.
Вычисление объема необходимых модификаций по формуле AAF = 0,4 +0,3CM + 0,3IM
Если AAF <= 0,5 определяем эквивалентное количество исходных строк по формуле: ESLOC = (ASLOC[AA + AAF(1 + 0,02 * SU * UNFM)]))/100
Если AAF <= 0,5 - ESLOC = (ASLOC[AA + AAF + SU * UNMF])/100
Значение ASLOC является общим размером компонентов, подлежащих модификации, выраженным в логических строках текста.
Пример
Предположим, в библиотеке Икс удалось найти классы, поддерживающие функции получения, хранения и распределения лекарств, аналогичные тем, которые требуются в новом приложении. Объем модифицированных компонентов составил около 2000 строк. Установлено, что за счет адаптации будет реализовано 50% функций проекта (DM) и 40% строк его программного текста (CM), а затраты на интеграцию (IM) будут снижены на 20%. Отсюда, значение AAF (общий объем модификаций) составит 26,12%. Известно, что исходный текст достаточно ясный и документированный, поэтому параметр понятности (SU) примем равным 10%. Поскольку аналитики и программисты хорошо знают тексты повторно используемых программ, примем UNFM равным 0. Выяснилось, что для определения расположения методов и классов достаточно выполнить простой поиск, поэтому значение АА можно принять равным 2, т.е. максимальному значению ... В результате вычислений получаем ESLOC = 562
Вычтем полученное значение эффективного количества строк текста ESLOC из значения параметра SLOC (строк кода нового проекта), использованного при определении исходного объема трудозатрат. Повторение расчетов с новым значением дает результат, равный 1,87 человеко-месяцев. Таким образом за счет повторного использования в новом проекте удалось сократить объем трудозатрат на 28%
Эдвард Йордон (Edward Yourdon) в "Возрождение американского программиста" (Rise and Resurrection of American Programmer) , обсуждая повторное использование кода, пишет: "Когда в 1994 году я спросил одного программиста в Microsoft'е о повторном использовании кода, его ответ (не для записи) был очень интересен: "Здесь каждый программист", он сказал мне, "твердо верит, что он единственный компетентный программист во всем заведении; все остальные - идиоты. Зачем бы вы стали использовать [в своей программе] код, написанный идиотами?"
---
По-настоящему качественный твидовый пиджак – как он должен выглядеть? Ответ на вопрос даст блог Игоря Пронина о современной моде и одежде.
Свободное ПО прочно входит в нашу жизнь, не удивлюсь, если в ближайшем будущем мы увидим утюги и пылесосы с открытым кодом. С каждым днем наблюдаю в сети все больше казуальных игр, созданных линуксоидами. Поглазеть на лучшие экземпляры и скачать игры бесплатно можно пройдя по ссылке.