Написание метода, который принимает один или несколько параметров в качестве входных данных, а затем возвращает различные выходные данные, которые зависят от логики функции, часто определяется как задание архитектуры решения.
Этот пост будет посвящен Принципам проектирования OOPS и тому, как они каким-то образом дополняют Принципы дизайна для разработки программного обеспечения. Все принципы в SOLID так или иначе связаны друг с другом, и можно следовать любому из них для лучшей разработки кода.
Следуйте любому принципу (скажем, "открыть-закрыть"), и через некоторое время разработки кода вы обнаружите, что на самом деле соблюдаете все принципы. :) Потому что все эти принципы разработаны с учетом одного - разработки высококачественного программного обеспечения.
O (принцип открытия-закрытия): классы (модули или функции) должны быть открыты для расширений, но закрыты для модификаций.
Параметры должны быть параметризованы таким образом, чтобы класс можно было переопределить.
OCP предлагает рассматривать некоторые исправления ошибок как расширения, а не как модификации.
Это проясняет принцип единой ответственности. Класс должен уметь выполнять только определенный вид задачи. Добрый означает чтение данных. Данные могут быть прочитаны из одного типа файла или из многих типов файлов. Например, может быть класс с именем DataReader () и у него может быть много методов. csv_reader (), excel_reader (), db_reader (), txt_reader (), поэтому теперь единственная ответственность класса - «читать данные» :) любые данные любыми способами, кроме чтения данных. :)
Любой класс, который мы собираемся написать, должен быть написан в том виде, в каком он может быть расширен, но не требует внесения новых изменений в код класса.
Принцип разделения интерфейса: (I от SOLID)
1. Ни один клиент не должен зависеть от методов, которые он не использует.
2. Класс должен быть разработан таким образом, чтобы у соавторов был максимально узкий интерфейс.
3. Если вы используете Python, должны присутствовать случаи модульного тестирования, потому что мы используем Python!
Классы, реализующие интерфейсы, не должны быть принуждены к реализации методов, которые они (классы) не используют. (Используйте маленькие интерфейсы, а не FAT) Не создавайте толстые интерфейсы.
Нам нужны разные потоки для чтения и записи.
Клиент должен зависеть от наименьшего набора методов и атрибутов. Наименьшее количество методов или атрибутов.
Разделение определяет разделение функций (не функций программирования) Программного обеспечения на два или более разных класса для облегчения доступа клиента к функциям.
D: принцип инверсии зависимостей.
1. Приложения должны использовать код абстрактного класса, ведущий к внедрению.
2. В таком языке, как Python, мы можем использовать файл settings.py для выполнения подобных задач.
Модули высокого уровня не должны зависеть от модулей низкого уровня. Абстракции не должны зависеть от деталей, детали должны зависеть от абстракций. В каждом модуле должен быть один «слой абстракции», чтобы можно было тестировать поведение классов, даже не глядя на классы.
L: (Принцип подстановки Лискова):
Поведение подкласса должно быть таким же правильным, как поведение суперкласса.
Если вы будете следовать принципу подстановки Лискова, ваши классы будут неявно следовать принципам Open / Close.
Заменяемость - это принцип объектно-ориентированного программирования, гласящий, что в компьютерной программе, если S является подтипом T, тогда объекты типа T могут быть заменены объектами типа S (т. Е. Объект типа T может быть заменен любым объект подтипа S) без изменения каких-либо желаемых свойств T (правильность, выполненная задача и т. д.).
Принцип единой ответственности:
У класса должна быть только одна причина для изменения.
GRASP: ›››› Общий принцип распределения ответственности.
- Контроллер и создание
- Высокая сплоченность и косвенность
- Высокая сплоченность: особенности, которые неотделимы друг от друга.
- Высокая сплоченность объединены в единую ответственность.
- Сложная часть - это уровень абстракций.
Почему нам стоит подумать о GRASP?
Информационный эксперт
Pure Fabrication
Низкое сцепление
Полиморфизм
Защищенные варианты
