Категории или частичные классы: образец для устранения «божьего объекта» Запах кода?

Question

Класс слишком велик и с ним трудно работать.В Objective-C я хотел бы использовать Категории, чтобы разбить класс, но тогда: разве категории не будут просто делить дом, полный слишком большого количества мусора, на комнаты?Полагаю, тот же вопрос относится и к частичным классам в C #.

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

Answer 1

Очень хороший принцип, на который можно сослаться, это ТВЕРДЫЙ принцип . В частности, «S» означает «Единственная ответственность»

Принцип единой ответственности

понятие, что объект должен иметь только одну ответственность.

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

Другими словами:

• код, который вы имеете в классе, должен быть разбит на разные классы в соответствии с принципом единой ответственности
• исходный класс Бога становится составным или фасадом : он использует все новые классы, предоставляет те же методы остальной части системы, но не реализует никаких функций в Сам, помимо «преобразования» вызовов божьего класса старого стиля в вызовы SOLID нового стиля.

Это означает, что регионы не делают ровно ничего для решения вашей проблемы с объектно-ориентированной точки зрения. На самом деле они на самом деле контрпродуктивны, поскольку способствуют скрытию проблемы.

См. Также эту статью Джеффа Этвуда:

http://www.codinghorror.com/blog/2008/07/the-problem-with-code-folding.html

Answer 2

Я должен признать, что никогда не использовал Objective-C, но, конечно, я использовал C #.

Сказал, что частичные классы - это то же самое, что классы, разделение класса на несколько файлов не делаеткласс поменьше, только в файле.Использование класса будет таким же.

Так что я не согласен, что частичные классы решат эту проблему, они были изобретены в основном для других вещей, таких как формы Windows, wpf, автоматически сгенерированный код.Они также полезны в других ситуациях, когда классы не могут быть логически разделены, но обычно этого следует избегать.

Я думаю, что вам следует разделить ваш класс на несколько классов, класс начинает пахнуть после 1k LOC (строк кода), также если класс разделен на несколько файлов.

Используйте наследование или разделите класс на несколько классов, связанных полями и свойствами.В примере, представленном chemicalNova, я бы разбил его на несколько классов, а не на несколько файлов.

Answer 3

Я помню, когда я был новичком, у нас был этот класс богов "BusinessService" или что-то подобное. Каждый раз, когда кто-то блокировал его в TFS, вам не повезло. Так что у меня возникла блестящая идея, почему бы нам не разбить ее на частичные занятия? В итоге мы получили что-то вроде «BusinessService1.cs» .. «BusinessService6.cs». Это был полный беспорядок, и полное разочарование, чтобы найти, где вещи.

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

Answer 4

Нет ничего плохого в разбиении класса на частичные.Это то, что немногие разработчики используют в своих интересах.

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

Например, если у меня есть «UserService», который находится на уровне данных, я мог бы разделить его на несколько частей, например:

UserServiceQueries.cs
UserServiceUpdates.cs
UserServiceInserts.cs
UserServiceLogicalFunctions.cs

.. однако они содержат частичные классы "UserService".Обычно я не часто использую ORM, так что это идеально для меня, потому что каждая часть связанной функциональности может стать довольно большой (очевидно, это базовый пример).

В заключение: воспользуйтесь преимуществами того, что предоставляется,Если вы чувствуете запах кода из-за того, что у вас огромный класс ... у вас есть только 2 варианта ... переписать его или разбить на части (если он определенно должен быть таким большим).

Myмнение в любом случае.