How Much Cohesion Is Enough?

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Какой способ лучше: books.del(42) или books.book(42).del()? Я использую оба и редко могу сказать, что один лучше другого. Первый вариант короче, в то время как второй более объектно-ориентированный. Первый вариант сложнее расширить, в то время как второй более громоздкий и требует больше строк кода, что означает больший шанс допустить ошибку. Какой вариант вы предпочитаете?

Конечно, подойдет любой вариант, но вопрос в том, какой дизайн более объектно-ориентированный? Кажется, что это зависит от размера объекта books. Если он небольшой, нет необходимости сначала получать книгу, мы можем просто удалить ее прямо там.

Однако, если это больше, лучше сначала получить «книгу»:

Существует ли явная жесткая граница между этими двумя? Есть ли строгое правило или, возможно, неоднозначный вопрос “Этот класс уже достаточно большой?” всегда должен быть решен голосованием?

Попробуем дать два крайних ответа: 1) никогда не достаточно большой, и 2) всегда достаточно большой.

  • Если класс всегда достаточно хорош для извлечения, мы получим много маленьких классов, методов с почти отсутствующими аргументами и … лучшую объектно-ориентированную архитектуру.

Общим знаменателем является согласованность.

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

Таким образом, второй вариант лучше? Да, это так. Меньшие классы, большая согласованность… но больше возможностей потерять фокус и распределить функциональность по слишком многим местам. “Все методы в одном объекте” - это более популярный дизайн, даже несмотря на его меньшую согласованность, именно потому, что его легче создать: просто поместите все в одно место и закончите. Позже, конечно, возникнут проблемы с поддержкой.

Главное заключается в том, что в этом случае нет четкого различия между правильным и неправильным дизайном. Мы просто должны сделать все возможное, чтобы сохранить классы с высокой согласованностью, уменьшая количество методов в каждом из них. Если есть всего несколько методов, нет необходимости извлекать Book, но как только количество методов становится больше, Book становится идеальным кандидатом для определения новой сущности.

Сколько методов является приемлемым?

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

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 13:35

sixnines availability badge   GitHub stars