Главная

Clean Classes

Что следует учить вместе с ООП

Поделиться:
 

11+

Статьи о Clean Code заходят очень даже неплохо! В прошлых статьях я уже рассматривал, как писать чистый код, функции и как разбивать все на модули. Код также можно группировать в более высокоуровневые формы организации, а именно в классы.

Иногда мы хотим, чтобы наши функции были «private», но при этом нужно, чтобы они были доступны через тесты. Мы используем модификаторы доступа для достижения инкапсуляции. Потеря инкапсуляции — это, вообще говоря, крайность.
Правило, которое нужно всегда помнить при написании классов: Классы должны быть небольшими!

Маленькие классы — это ключевое правило. Вы, наверное, задаетесь вопросом: “Насколько маленькими должны быть классы?”

Когда мы говорим о размерах функций, то обычно подразумеваем количество строк, но когда дело касается классов, то следует брать во внимание лишь количество их «обязанностей». Также важно, чтобы функционал любого класса можно было описать 25 словами. (не считая «если», «и», «или» и так далее).

Давайте посмотрим на пример:

Класс кажется небольшим, но на самом деле у него разные обязанности: управление фокусом и получение номера билда.
Помните SRP — принцип единой ответственности? (single responsibility principle)

У класса или модуля должна быть только одна ответственность. SRP — одна из наиболее важных концепций объектно-ориентированного программирования. Это также одна из самых простых концепций для понимания. SRP часто является наиболее часто используемым принципом проектирования классов, потому что заставить программное обеспечение работать и сделать его чистым — это два совершенно разных действия.

В любом случае давайте разделим этот класс на два отдельных класса:

И еще…

Бинго! Это выглядит так чисто и лаконично! Проблема в том, что многие из нас думают, что все готово, когда код работает. Никогда не следует забывать об организации и чистоте кода. Мы переходим к следующей проблеме вместо того, чтобы возвращаться и разбивать перегруженные классы на отдельные блоки с единой ответственностью.

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

Связность

В наших классах будут переменные экземпляра и функции, которые будут манипулировать этими переменными. Чем большим количеством переменных управляет метод, тем более связным он является для класса.

Класс, в котором каждая переменная экземпляра обрабатывается каждым методом, является максимально связным. Следовательно, связность — это просто мера того, насколько переменные и методы логически связаны друг с другом.
Когда связность высока, это означает, что методы и переменные класса взаимозависимы и держатся вместе как логическое целое.

Чем больше связность, тем лучше архитектура программы.

В этом примере функции push() и pop() изменяют два элемента переменных экземпляра и topOfStack. Следовательно, этот код довольно связный. Для достижения связности необходимо разбить класс на гораздо более мелкие атомарные классы. Всякий раз, когда класс теряет связность, нужно попытаться разделить его.

Есть несколько типов связности:

• Случайная связность — незапланированная, случайная, являющаяся результатом модульности кода. Поскольку такая связность случайна, это неприемлемо, так как может сбивать с толку.
• Логическая связность — когда вы планируете и объединяете логически связанные утверждения и инструкции в один модуль.
• Процедурная связность — когда элементы модуля объединяются для выполнения одной задачи.
• Коммуникационная связно — когда элементы сгруппированы вместе, выполняются последовательно и работают с одними и теми же данными.
• Временная связность — когда элементы структурированы так, что они обрабатываются в один и тот же момент времени.
• Последовательная связность — когда выход одного элемента служит входом для следующего, и они структурированы вместе.
• Функциональная связность — когда элементы вносят свой вклад в выполнение одной четко определенной функции.

Старайтесь писать чистый код!

11+