В первой статье я немного затронул тему полей и методов классов. Сейчас расскажу более подробно. Атрибуты (они же поля классов), в зависимости от степени детализации диаграммы, могут описывать несколькими характеристиками: имя, тип и значение по-умолчанию – это базовый набор.
В общем виде, синтаксис описания атрибута выглядит так:
<видимость> <имя> : <тип> = <значение по-умолчанию>.
<видимость> в данном случае может быть public(+), protected(#) и private(-).
С концептуальной точки зрения атрибуты мало отличаются от ассоциаций. Скорее – это их частный вид, подразумевающий единственное значение. Атрибуты могут быть обязательными и не обязательными. Для необязательных атрибутов указывается их кратность так:
Discount [0...1]: double.
Читать далее »
По мере разработки любой сложной системы выясняется, что необходимо переместить то или иное поле или метод в новый класс. Любое правильное проектное решение через некоторое время может оказаться неправильным.
Суть приема перемещения поля такая же, как и у приема перемещения метода – переместить поле в тот класс, в который его больше всего использует. Причем под использованием здесь подразумевается и косвенное – через методы доступа. Еще, например, есть прием выделения класса, о котором я не говорил. Это противоположный встраиванию класса прием. Так вот, при выделении класса сначала перемещаются поля, а затем – методы.
Пусть у нас есть все те же (я о них упоминал в предыдущих статьях) взаимодействующие классы Account и AccountType: Читать далее »
Продолжаю серию статьей про антипаттерны, в которых описываются самые частые ошибки программистов всех уровней, причины этих ошибок и их последствия (иногда даже буду писать, как их исправлять).
Сегодня будем рассматривать антипаттерн под названием “Cut-and-Paste” ( копипаст если по-русски 
).
Суть этого антипаттерна заключается в том, что для облегчения своей задачи, программисты прибегают к клонированию похожих кусков кода (а вместе с ними и ошибки) внутри одного проекта или между разными проектами.
Вокруг проекта, в котором применялся такой антипаттерн, часто можно слышать выражения вроде “Эй! Вы же уже исправляли этот баг, почему он снова появился?”
Читать далее »
В прошлой статье из цикла рефакторинга про встраивание класса я писал, что расскажу о таких приемах, как «Перемещение метода» и «Перемещение поля». Сегодня время пришло написать об одном из них – о первом.
Иногда метод чаще использует функции другого класса (или наоборот – используется ими), чем своего собственного. Выход из такой ситуации здесь состоит в том, чтобы создать аналогичный метод в том классе, функции которого этот метод чаще использует.
Но этот прием не всегда удается провести. Если нет уверенности в его необходимости – то лучше не стоит, особенно в крупных проектах. Почему? Сами знаете 
Порядок применения приема состоит в следующем. Читать далее »
В прошлой статье про UML, я описал в общих чертах диаграмму одиночного класса. Сегодня я постараюсь описать то, как связывать диаграммы отдельных классов в единую картинку. Но прежде, я хотел бы сделать небольшое теоретическое отступление, особо важное для понимания сути диаграмм, в начале пути.
Как я раньше уже замечал, основное назначение диаграмм – это представление структуры вашего кода в наглядном и понятном другим программистам виде. Но, я не сказал в каком контексте это “знание о программе” следует понимать.
Нет конкретных требований к построению диаграмм классов для всех программы. Например, не обязательно покрывать весь код этими диаграммами, а можно просто нарисовать на них основные моменты. Есть программисты, которые придерживаются этой точки зрения, а есть, которые предпочитают отображать всю картину в деталях.
Читать далее »
Представим себе такую ситуацию, когда мы провели серию приемов рефакторинга и в результате оказалось, что от класса становится мало пользы, т.к. в нем осталось мало функций. Проблема, которая может быть решена с помощью сегодняшнего приема, – это устранение малого класса. Хотя это, конечно, не проблема. Но все же
Суть приема встраивания класса состоит в том, чтобы встроить имеющиеся функции нашего класса А в другой класс Б, который чаще всего использует функции класса А. Сам класс А при этом удалить.
Подробно я описывать процесс не буду. Приведу лишь небольшой пример, который далее можно разобрать самостоятельно.
Допустим у нас есть два класса – Person и PhoneNumber. При этом класс Person использует методы класса PhoneNumber: Читать далее »
Все, кто занимается разработкой ПО достаточно долго, уже много раз слышали про такую стадию разработки программы, как проектирование. Тем не менее, эта стадия практически всегда остается только в умах программистов, причем в довольно абстрактном виде. У каждого свои ассоциации с этим термином, но в основном, под ним кроется что-то скучное, ненужное и трудное для понимания. На самом деле все гораздо проще и в этом цикле статьей я Вам это докажу. Начиная с самых очевидных азов проектирования, очевидных даже для новичков, мы дойдем до современных методов(я надеюсь ), которые применяются в больших проектах класса Enterprise.
Так как любая программа является системой, в том или ином виде, то в ней можно выделить составные части и определить их взаимосвязи. Для таких описаний используется общепринятый язык UML (Unified Modeling Language) или Унифицированный Язык Моделирования. В самых общих чертах, любая информация, записанная на этом языке, представляет собой набор диаграмм, которые довольно легко читаются.
Читать далее »
