ООП, класс / объекты излишни

Question

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

Answer 1

SOLID может помочь, если класс плохо спроектирован, но не поможет ответить на вопрос типа «Является ли объектно-ориентированное программирование лучшим подходом к этой проблеме?»

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

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

Если вы плохо знаете объектно-ориентированный язык, возможно, объектно-ориентированное программирование не для вас.

Если ваша организация не знает и не может поддерживать объектно-ориентированные решения, возможно, объектно-ориентированное программирование не для вас.

Answer 2

Многие люди скажут, что «ТВЕРДЫЕ Принципы» являются хорошим ориентиром для дизайна класса.

Есть много статей / подкастов, касающихся Принципов ТВЕРДОГО, просто сделайте быстрый поиск. Вот хорошее начало:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 3

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

• класс является коллекцией связанных состояний и поведения
• поведение должно использовать только параметры состояния и метода
• если вы рассматриваете состояние как отношение (то есть как столбцы в таблице реляционной базы данных), идентификатор объекта (указатель) является первичным (синтетическим) ключом, а состояние содержит неключевые атрибуты. Находится ли объект в третьей нормальной форме? Если нет, разделите его на два или более объекта.
• завершен ли жизненный цикл объекта? Другими словами, есть ли у вас достаточно методов, чтобы вывести объект из создания через использование и, наконец, уничтожить / утилизировать? Если нет, то какие методы (или состояния / переходы) отсутствуют?
• все ли состояния используются хотя бы одним методом? Если нет, предоставляет ли он описательную информацию, полезную для пользователя объекта? Если ответ на оба эти вопроса - нет, тогда избавьтесь от постороннего состояния.

если проблема, которую вы пытаетесь решить, не требует состояния, вам не нужен объект.

Answer 4

Один из лучших показателей, которые я когда-либо нашел для плохого дизайна в целом, - это рецензирование.

Answer 5

Помимо принципов SOLID, обратите внимание на запахи кода. Они были упомянуты первыми (IIRC) в книге Мартина Фаулера «Рефакторинг», которая отлично читается.

Запахи кода обычно применяются к ОО, а также в некоторой степени к процессуальной разработке, включая такие вещи, как «Хирургия дробовика», где требуются правки по всей базе кода, чтобы изменить одну маленькую вещь, или «Запах случая переключения», когда гигантские случаи переключения управляют поток вашего приложения.

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