Принципы дизайна

Какие принципы вы обычно придерживаетесь при разработке классов?

Ответы

Ответ 1

Принципы объектно-ориентированного проектирования классов (принципы "SOLID" )

  • SRP: Единая ответственность Принцип Класс должен иметь один, и только один, причина для изменения.
  • OCP: принцип открытого закрытия. должен иметь возможность расширять классы поведение, не изменяя его.
  • LSP: Замена Лискова Принцип Производные классы должны быть подставляемые для их основания классы.
  • ISP: Разделение интерфейса Принцип Сделайте мелкозернистый интерфейсы, специфичные для клиента.
  • DIP: зависимость Принцип инверсии Зависит от абстракции, а не на конкрециях.

Источник: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Ответ 3

S.O.L.I.D. принципы.
Или, по крайней мере, я стараюсь не слишком уклоняться от них.

Ответ 4

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

Это и CRC (класс, ответственность, соавторы) (записывайте карту вниз в свои файлы заголовков, а не на фактические карты, потому что они легко понимают документацию)

Ответ 6

Как уже упоминалось выше, некоторые фундаментальные принципы объектно-ориентированного проектирования - это OCP, LSP, DIP и ISP.

Отличный обзор их Роберта К. Мартина (из Object Mentor) можно найти здесь: Принципы и шаблоны OOD

Ответ 7

"" Инициализация ресурсов") парадигма удобна, особенно при написании на С++ и работе с ресурсами операционной системы (файловые дескрипторы, порты и т.д.).

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

Ответ 8

слабосвязанный, высокосвязный.

Состав над наследованием.

Ответ 9

Проект, управляемый доменом, как правило, является хорошим принципом.

Ответ 10

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

Ответ 11

СОЛИДНЫЕ принципы и шаблон Лискова, а также шаблон единой ответственности.

Ответ 12

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

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

Ответ 13

Обычно я стараюсь подгонять класс в один из шаблонов проектирования