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

Принципы объектно-ориентированного проектирования классов («ТВЕРДЫЕ» принципы)

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

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

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

Модель ТВЕРДЫЙ. принципы.
Или, по крайней мере, я стараюсь не слишком сильно от них уклоняться.

Парадигма «Приобретение ресурсов - это инициализация» удобна, особенно при написании на C++ и работе с ресурсами операционной системы (дескрипторами файлов, портами и т. д.).

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

Я обычно стараюсь уместить класс в один из оо шаблоны проектирования.

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

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

Превосходный обзор этого от Роберта К. Мартина (из Object Mentor) доступен здесь: Принципы и шаблоны OOD

слабосвязанная, очень связная.

Композиция превыше наследования.

Не забывайте Закон Деметры.

Принципы SOLID и шаблон Лискова вместе с шаблоном единой ответственности.

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

Это и карточки CRC (Class, Responsibility, Collaborators) (запишите карточку в ваших файлах заголовков, а не на настоящих карточках, потому что документация также проста для понимания)

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

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