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

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

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

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

Видео (дядя Боб): Чистое кодирование Роберта К. Мартина (дядя Боб)

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

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

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

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

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

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

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

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

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

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

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

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

Принципы SOLID и паттерн Лискова, а также паттерн Единственная ответственность.

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

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

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