От новичка до профессионала

В первой статье я немного затронул тему полей и методов классов. Сейчас расскажу более подробно. Атрибуты (они же поля классов), в зависимости от степени детализации диаграммы, могут описывать несколькими характеристиками: имя, тип и значение по-умолчанию – это базовый набор.

В общем виде, синтаксис описания атрибута выглядит так:

<видимость> <имя> : <тип> = <значение по-умолчанию>.

<видимость> в данном случае может быть public(+), protected(#) и private(-).

С концептуальной точки зрения атрибуты мало отличаются от ассоциаций. Скорее – это их частный вид, подразумевающий единственное значение. Атрибуты могут быть обязательными и не обязательными. Для необязательных атрибутов указывается их кратность так:

Discount [0...1]: double.
Читать далее »

По мере разработки любой сложной системы выясняется, что необходимо переместить то или иное поле или метод в новый класс. Любое правильное проектное решение через некоторое время может оказаться неправильным.

Суть приема перемещения поля такая же, как и у приема перемещения метода – переместить поле в тот класс, в который его больше всего использует. Причем под использованием здесь подразумевается и косвенное – через методы доступа. Еще, например, есть прием выделения класса, о котором я не говорил. Это противоположный встраиванию класса прием. Так вот, при выделении класса сначала перемещаются поля, а затем – методы.

Пусть у нас есть все те же (я о них упоминал в предыдущих статьях) взаимодействующие классы Account и AccountType: Читать далее »

Продолжаю серию статьей про антипаттерны, в которых описываются самые частые ошибки программистов всех уровней, причины этих ошибок и их последствия (иногда даже буду писать, как их исправлять).

Сегодня будем рассматривать антипаттерн под названием “Cut-and-Paste” ( копипаст если по-русски ).

Суть этого антипаттерна заключается в том, что для облегчения своей задачи, программисты прибегают к клонированию похожих кусков кода (а вместе с ними и ошибки) внутри одного проекта или между разными проектами.

Вокруг проекта, в котором применялся такой антипаттерн, часто можно слышать выражения вроде “Эй! Вы же уже исправляли этот баг, почему он снова появился?”
Читать далее »

В прошлой статье из цикла рефакторинга про встраивание класса я писал, что расскажу о таких приемах, как «Перемещение метода» и «Перемещение поля». Сегодня время пришло написать об одном из них – о первом.

Иногда метод чаще использует функции другого класса (или наоборот – используется ими), чем своего собственного. Выход из такой ситуации здесь состоит в том, чтобы создать аналогичный метод в том классе, функции которого этот метод чаще использует.

Но этот прием не всегда удается провести. Если нет уверенности в его необходимости – то лучше не стоит, особенно в крупных проектах. Почему? Сами знаете

Порядок применения приема состоит в следующем. Читать далее »

В прошлой статье про UML, я описал в общих чертах диаграмму одиночного класса. Сегодня я постараюсь описать то, как связывать диаграммы отдельных классов в единую картинку. Но прежде, я хотел бы сделать небольшое теоретическое отступление, особо важное для понимания сути диаграмм, в начале пути.

Как я раньше уже замечал, основное назначение диаграмм – это представление структуры вашего кода в наглядном и понятном другим программистам виде. Но, я не сказал в каком контексте это “знание о программе” следует понимать.

Нет конкретных требований к построению диаграмм классов для всех программы. Например, не обязательно покрывать весь код этими диаграммами, а можно просто нарисовать на них основные моменты. Есть программисты, которые придерживаются этой точки зрения, а есть, которые предпочитают отображать всю картину в деталях.
Читать далее »

Представим себе такую ситуацию, когда мы провели серию приемов рефакторинга и в результате оказалось, что от класса становится мало пользы, т.к. в нем осталось мало функций. Проблема, которая может быть решена с помощью сегодняшнего приема, – это устранение малого класса. Хотя это, конечно, не проблема. Но все же

Суть приема встраивания класса состоит в том, чтобы встроить имеющиеся функции нашего класса А в другой класс Б, который чаще всего использует функции класса А. Сам класс А при этом удалить.

Подробно я описывать процесс не буду. Приведу лишь небольшой пример, который далее можно разобрать самостоятельно.

Допустим у нас есть два класса – Person и PhoneNumber. При этом класс Person использует методы класса PhoneNumber: Читать далее »

Все, кто занимается разработкой ПО достаточно долго, уже много раз слышали про такую стадию разработки программы, как проектирование. Тем не менее, эта стадия практически всегда остается только в умах программистов, причем в довольно абстрактном виде. У каждого свои ассоциации с этим термином, но в основном, под ним кроется что-то скучное, ненужное и трудное для понимания. На самом деле все гораздо проще и в этом цикле статьей я Вам это докажу. Начиная с самых очевидных азов проектирования, очевидных даже для новичков, мы дойдем до современных методов(я надеюсь ), которые применяются в больших проектах класса Enterprise.

Так как любая программа является системой, в том или ином виде, то в ней можно выделить составные части и определить их взаимосвязи. Для таких описаний используется общепринятый язык UML (Unified Modeling Language) или Унифицированный Язык Моделирования. В самых общих чертах, любая информация, записанная на этом языке, представляет собой набор диаграмм, которые довольно легко читаются.
Читать далее »