ГЛАВНАЯ     АРХИВ     НАПИСАТЬ АДМИНУ     ПОДПИСАТЬСЯ НА RSS     ВОЙТИ      

Поиск

Категории

Облако тегов

  << Предыдущий пост       Следующий пост >>  
От: inbruk
6. августа 2014 19:24

разработка ПО

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

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

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

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

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

Бертран Мейер в основном известен как основоположник термина Принцип открытости/закрытости, который появился в 1988 году в его книге Object-Oriented Software Construction. Идея была в том, что однажды разработанная реализация класса в дальнейшем требует только исправления ошибок, а новые или изменённые функции требуют создания нового класса. Этот новый класс может переиспользовать код исходного класса через механизм наследования. Производный подкласс может реализовывать или не реализовывать интерфейс исходного класса.

Определение Мейера поддерживает идею наследования реализации. Реализация может быть переиспользована через наследование, но спецификации интерфейса могут измениться. Существующая реализация должна быть закрыта для изменений, но новые реализации не обязаны использовать существующий интерфейс.

В течение 1990-х принцип открытости/закрытости стал де-факто переопределён для применения с абстрактными интерфейсами, реализации которых могут быть изменены, и могут быть созданы множественные реализации и полиморфно замещены одна на другую.

Полиморфный принцип открытости/закрытости

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

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

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

В двух словах: Методы, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.

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

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

В двух словах: Клиенты не должны зависеть от методов, которые они не используют.

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

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

Похожие записи


Вопросы на собеседовании C#, Net, ASP.NET, SQL
Продолжая тему вопросов на собеседовании. Нашел еще одну подборку. Оригинал лежит здесь . Перенес, чтобы не затерялось. Есть вполне вменяемые ответы (хотя, на некоторые вопросы ответил бы по-другому). Ответы находятся после списка вопросов, я их не менял. 23. Что такое шаблон проектирования Model/View/Controller? Как и зачем его применяют? 2...

Silverlight, HTML5 и непрозрачная стратегия развития Microsoft
Оригинал статьи взят отсюда: Silverlight, HTML5 и непрозрачная стратегия развития Microsoft Автор: Peter Bright Переводчик: Mairon     По непонятным мне на данный момент причинам, похоже, что многие разработчики, присутствовавшие на недавней конференции PDC-2010 (Крупнейшая конференция Microsoft для разработчиков — Прим. переводчика), были сильн...

Мартин Ньюкирк Косс - Быстрая разработка программ: принципы, примеры, практика
Название: Быстрая разработка программ: принципы, примеры, практика Автор: Роберт К. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс Издательство: Вильямс ISBN: 5-8459-0558-3 Год: 2004 Страниц: 752 От издателя: Роберт Мартин в соавторстве с Джеймсом Ньюкирком и Робертом Коссом предлагает вниманию читателей книгу о различных методиках быстрого (и даже ...

Комментарии

 
nomad 13.10.2014 10:49:43 #

знают про них многие, применяют - далеко не все

Добавить комментарий




biuquote
  • Комментарий
  • Предпросмотр
Loading


  Сохранить комментарий