coding4.net Голосов: 1 Адрес блога: http://www.coding4.net/ Добавлен: 2012-06-11 20:16:46

SOLID - 5 архитектурных принципов при создании объектно-ориентированных программ

2014-08-06 19:24:00 (читать в оригинале)




Иногда на собеседованиях на должность программиста спрашивают: что такое SOLID ? В этом посте будет разъяснен этот вопрос.

1) Single Responsibility Principle - принцип единственной обязанности

Это простейший для понимания принцип, но сложный для использования. Принцип единственной обязанности значит, что объект имеет только одну обязанность и она полностью инкапсулирована в класс. Все его методы и свойства нужны только для обеспечения этой обязанности и только ее. И как следствие, класс или модуль могут быть изменены только по одной причине. Например если есть модуль, который создает и печатает отчет. В таком случае может измениться содержимое отчета. Может измениться формат отчета. Может измениться способ печати. Соответственно любое из этих изменений повлечет переделку модуля, так как он отвечает не за одну вещь, а за три. Это является плохим проектным решением. В этом случае принцип нарушен и нужно разделить модуль на три. Тогда изменять и поддерживать модули будет проще. Соблюдение принципа единственной обязанности делает класс, да и проект в целом более здоровым.

2) Open/Closed Principle - принцип открытия для расширения, но закрытия для изменения

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

3) Liskov Substitution Principle - принцип замещения Лисков

Функции, которые используют ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом. Впервые этот принцип был упомянут Барбарой Лисков в 1987 году на научной конференции, посвященной объектно-ориентированному программированию. Этот принцип является важнейшим критерием для оценки качества принимаемых решений при построении иерархий наследования. Сформулировать его можно в виде простого правила: тип S будет подтипом Т тогда и только тогда, когда каждому объекту oS типа S соответствует некий объект oT типа T таким образом, что для всех программ P, реализованных в терминах T, поведение P не будет меняться, если oT заменить на oS.

4) Interface Segregation Principle - принцип изоляции интерфейса

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

5) Dependency Inversion Principle - принцип обращения зависимости

Классы и модули верхних слоев не должны зависеть от модулей и классов нижних. И те и другие должны зависеть только от абстракций. Абстракции не должны зависеть от деталей. Реализация должна зависеть от абстракций. Принцип обращения зависимостей говорит лишь о корректном разделении проекта на слои с использованием интерфейсов.