Когда класс слишком большой или слишком маленький?

Недавно я просмотрел мой код у старшего разработчика в моей компании. Он критиковал мой дизайн за использование слишком большого количества классов. Мне интересно услышать ваши реакции.

Мне было поручено создать службу, которая создает xml файл в результате манипулирования тремя другими файлами xml. Назовите эти aaa.xml, bbb.xml и ccc.xml. Услуга работает в два этапа. В первой фазе он сглаживает aaa.xml против bbb.xml. На втором этапе он объединяет продукт первой фазы с ccc.xml для получения конечного результата.

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

Я думал, что мой подход хорош, потому что он держал мои классы маленькими и сплоченными. Мой подход также помог контролировать размер моего тестового класса.

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

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

Ответ 1

Если вы следуете принципу единственной ответственности (и исходя из тона вашего вопроса, я думаю, что вы его следуете), тогда ответ ясно:

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

Это очень широкое и действительно субъективное - следовательно, борьба с вашим коллегой. С вашей стороны вы можете утверждать:

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

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

Ответ 2

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

Здесь также стоит упомянуть принцип единой ответственности. Создание класса с единственной целью очистки и другое с единственной целью слияния следует этому принципу.

Я бы сказал, что ваш подход лучше всех.

Ответ 3

Что бы вы назвали классами? ScrubXml и MergeXml - хорошие имена. ProcessXML и ScrubAndMergeXml нет, первое из них слишком общее, а второе имеет конъюнкцию. Пока ни один из классов не полагается вообще на внутренности одного или других (т.е. Низкое сцепление), у вас там хороший дизайн.

Имена очень полезны при определении сплоченности. Коммуникативный модуль делает одно и, следовательно, имеет простое конкретное имя. Модуль, который делает больше чем одно, менее сплочен и нуждается в более общем или более сложном имени.

Одна проблема с объединением функциональности в X в Y, если X используется только Y, является абсурдом reductio ad absdamdam: если ваш график вызовов ацикличен, вы завершите все свои функции в одном классе.

Ответ 4

Как человек, который возвращается от строительного фестиваля GodClass в течение нескольких лет, и теперь очень стараюсь избежать этой ошибки в будущем; ошибка создания единичного источника с 6000 до 10000 строк с одним классом, с более чем 250 методами, 200 полей данных и некоторыми методами более 100 строк, принцип единой ответственности выглядит как нечто, достойное защиты от пристрастий вашего непросвещенного супервизора.

Если, однако, ваш руководитель и вы не согласны с вопросом, принадлежат ли 2000 строк кода одному классу или трем, то я думаю, что вы оба ближе к здравомыслящему, чем я. Возможно, это вопрос масштаба и перспективы. Некоторые объектно-ориентированные программисты любят определенную "Коэффициент автономности" для каждого класса, прямо нарушая общепринятые представления о том, как улучшить сцепление и минимизировать сцепление.

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

Ответ 5

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

Ответ 6

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

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

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