1. Принцип единой ответственности
Определение: Для класса должна быть только одна причина для его изменения.
Границы единоличной ответственности не столь четки, и часто их необходимо определять на личном опыте. Конечно, самой большой проблемой является определение обязанностей, что такое ответственность класса и как разделить обязанности класса.
2. Принцип открытия-закрытия
Определение: классы, модули, функции и т. д. должны быть расширяемыми, но не модифицируемыми.
Мы руководствуемся принципом открытого-закрытого.Когда программное обеспечение нуждается в изменении, мы должны сделать все возможное, чтобы добиться изменений путем расширения, а не модификации существующего кода. Четыре слова «следует попробовать» здесь указывают на то, что принцип OCP не означает, что исходный класс не должен модифицироваться. Когда мы чувствуем «запах коррупции» исходного кода, его следует рефакторить как можно раньше, чтобы код можно было восстановить в нормальном процессе «эволюции», а не добавлять новые реализации через интеграцию и т. д., что приводит набирать навороты и историю Избыточность унаследованного кода. Поэтому в процессе разработки вам необходимо самостоятельно рассмотреть конкретную ситуацию, сделать ли программную систему более стабильной и гибкой, изменив старый код или унаследовав его.Обеспечив удаление «повреждения кода», это также обеспечивает корректность оригинального модуля.
3. Принцип подстановки Лисков.
Примечание. Это одна из конкретных реализаций принципа открытого-закрытого, и его основным принципом является абстракция.
Определение: Все ссылки на базовый класс должны прозрачно использовать объекты его подклассов.
Основным принципом принципа подстановки Лисков является абстракция, а абстракция зависит от особенностей наследования.В ООП преимущества и недостатки наследования совершенно очевидны, а именно: (1) повторное использование кода, снижающее стоимость создания классов, каждый подкласс имеет атрибуты и методы родительского класса; (2) подкласс в основном похож на родительский класс, но отличается от родительского класса; (3) Улучшить масштабируемость кода. Недостатки наследства: (1) Наследование является инвазивным, пока наследование должно обладать всеми свойствами и методами Фрея; (2) Это может привести к избыточности и гибкости кода подкласса, потому что подкласс должен иметь свойства и методы Фрея. Принцип открытого-закрытого и принцип замещения Лисков часто взаимозависимы и неразделимы.Замещение Лисков используется для достижения развития расширений и закрытия модификаций.
4. Принцип обращения зависимости
Примечание. Это связано с масштабируемостью системы, способностью принимать изменения, принципом открытости-закрытости.
Определение: Модули высокого уровня не должны зависеть от модулей низкого уровня, оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей, а детали должны зависеть от абстракций.
Абстракция в Java относится к интерфейсу или абстрактному классу, ни один из которых не может быть создан напрямую; детали — это классы реализации, а детали, созданные при реализации интерфейса или интеграции абстрактного класса, также являются деталями, то есть объектами, которые могут быть реализованы. быть сгенерирован путем добавления ключевого слова yield new . Модуль высокого уровня — это вызывающая сторона, а модуль низкого уровня — конкретный класс реализации. Принцип инверсии зависимостей выражен в Java, что зависимости между модулями возникают через абстракцию, и нет прямой зависимости между классами реализации, и связь зависимости генерируется через интерфейсы или абстрактные классы. Если класс и класс напрямую зависят от деталей, то прямая связь будет долгое время. В результате, когда выполняется модификация, одновременно модифицируется зависимый код, что ограничивает масштабируемость.
5. Принципы разделения интерфейсов
Примечание. Сведите к минимуму, уменьшите зависимости и, таким образом, уменьшите риск изменений.
Определение: Зависимость класса от другого класса должна быть построена на минимальном интерфейсе.
Создавайте единый интерфейс, не создавайте огромный и раздутый интерфейс, старайтесь максимально усовершенствовать интерфейс, используя как можно меньше методов в интерфейсе. Другими словами, нам нужно создавать выделенные интерфейсы для каждого класса, а не пытаться создать огромный интерфейс для всех классов, которые зависят от его вызова. (1) Интерфейс должен быть как можно меньше, но должны быть ограничения. Уточнение интерфейса может повысить гибкость дизайна программы, но если он будет слишком маленьким, это вызовет слишком много интерфейсов и усложнит дизайн. Итак, будьте в меру. (2) Настроить службы для классов, которые зависят от интерфейса, и предоставлять только методы, необходимые вызывающему классу, и скрывать методы, которые ему не нужны. Минимальные зависимости можно установить, только сосредоточившись на предоставлении пользовательских сервисов для модуля. (3) Улучшить сплоченность и уменьшить внешнее взаимодействие. Методы интерфейса должны модифицироваться с помощью public как можно меньше. Интерфейсы — это внешние обязательства, чем меньше обязательств, тем лучше развивается система и тем меньше риск изменений.
Вышеуказанные пять принципов (единичная ответственность, принцип открытости-закрытости, замена Лискова, изоляция интерфейса, инверсия зависимостей) были определены дядей Бобом как принцип SOLID в начале 21 века. Будучи пятью основными принципами объектно-ориентированного программирования, при совместном использовании они делают программную систему более понятной, простой и наиболее открытой для изменений.
6. Закон Деметры, также известный как принцип наименьшего знания
Примечание. Уменьшите связь между существующими объектами, введя разумную третью сторону.
Определение: программный объект должен как можно меньше взаимодействовать с другими объектами.
Класс должен знать как можно меньше о классах, которые необходимо связать или вызвать.Чем ближе внутренняя реализация класса к вызывающей стороне или зависимостям, тем больше связь, и когда один класс изменяется, тем больше влияние на другой класс. . (1) При делении на классы следует создавать как можно больше слабосвязанных классов. Чем ниже степень сцепления между классами, тем выгоднее принимать. После изменения слабосвязанного класса это не слишком сильно повлияет на связанные классы. (2) При проектировании организации классов каждый класс должен попытаться уменьшить права доступа к своим переменным-членам и функциям-членам. (3) Что касается ссылок на другие классы, то ссылки класса на другие объекты должны быть сведены к минимуму.