Сообщения

Принцип разделения интерфейса (Interface segregation principle)

Изображение
В области разработки программного обеспечения принцип разделения интерфейса (ISP) гласит, что ни один клиент не должен быть вынужден зависеть от методов, которые он не использует. ISP разбивает очень большие интерфейсы на более мелкие и более специфичные, чтобы клиенты могли знать только о методах, которые им интересны. Такие сокращенные интерфейсы также называются ролевыми интерфейсами. ISP предназначен для поддержания развязанности (decoupled) системы и, таким образом, упрощения ее рефакторинга, изменения и повторного развертывания. ISP - это один из пяти SOLID принципов объектно-ориентированного проектирования, аналогичный принципу высокой связности (High Cohesion Principle) GRASP. Важность в объектно-ориентированном дизайне В объектно-ориентированном дизайне интерфейсы предоставляют уровни абстракции, которые упрощают код и создают барьер, предотвращающий связь с зависимостями. По мнению многих экспертов по программному обеспечению, подписавших Манифест программного мастерства,...

Принцип подстановки Лисков (Liskov substitution principle)

Изображение
Подстановочность - это принцип в объектно-ориентированном программировании, утверждающий, что в компьютерной программе, если S является подтипом T, объекты типа T могут быть заменены объектами типа S (то есть объект типа T может быть заменен любым объектом подтипа S) без изменения каких-либо желательных свойств программы (корректность, выполненная задача и т. д.). Более формально, принцип подстановки Лисков (LSP) - это конкретное определение отношения подтипов, называемого (сильным) поведенческим подтипом, которое было впервые введено Барбарой Лисков в основном выступлении на конференции в 1987 году под названием "Абстракция и иерархия данных". Это семантическое, а не просто синтаксическое отношение, поскольку оно призвано гарантировать семантическую совместимость типов в иерархии, в частности, типов объектов. Барбара Лисков и Джаннет Винг вкратце описали этот принцип в статье 1994 года: Требование к подтипу: Пусть ϕ(x) - свойство, доказываемое для объектов x типа T. Тогда...

Принцип открытости/закрытости (open/closed principle)

Изображение
В объектно-ориентированном программировании принцип открытости/закрытости (open/closed principle) гласит: "программные объекты (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации"; то есть такая сущность может допускать расширение (extend) своего поведения без изменения исходного кода самой сущности. Название принцип открытости/закрытости использовалось двумя способами. Оба способа используют обобщения (например, наследования или функции делегирования) для разрешения кажущейся дилеммы, но цели, методы и результаты различны. Принцип открытости/закрытости - один из пяти принципов SOLID объектно-ориентированного проектирования. Принцип открытости/закрытости Мейера Бертрану Мейеру обычно приписывают то, что он породил термин "принцип открытости/закрытости", который появился в его книге "Построение объектно-ориентированного программного обеспечения" 1988 года. Модуль будет считаться открытым, если он все еще дос...

Принцип единой ответственности (single responsibility principle)

Изображение
Принцип единой ответственности (single responsibility principle) - это принцип компьютерного программирования, который гласит, что каждый модуль, класс или функция должны нести ответственность за одну часть функциональности, предоставляемой программным обеспечением, и эта ответственность должна быть полностью заключена в класс, модуль или функцию. Все его услуги должны быть тесно связаны с этой ответственностью. Роберт К. Мартин выражает принцип следующим образом: "У класса должна быть только одна причина для изменения". История Термин был введен Робертом К. Мартином в одноименной статье, являющейся частью его "Принципов объектно-ориентированного проектирования", ставшую популярной благодаря его книге "Гибкая разработка программного обеспечения, принципы, шаблоны и практики". Мартин описал его как основанный на принципе сплоченности, как описано Томом ДеМарко в его книге "Структурный анализ и спецификация системы", и Мейлиром Пейдж-Джонсом в ...

Инверсия контроля (Inversion of control, IoC)

Изображение
В программной инженерии инверсия контроля (Inversion of control, IoC) является принципом программирования. IoC инвертирует поток управления по сравнению с традиционным потоком управления. В IoC пользовательские части компьютерной программы получают поток управления из общей структуры. Архитектура программного обеспечения с таким дизайном инвертирует управление по сравнению с традиционным процедурным программированием: в традиционном программировании пользовательский код, выражающий цель программы, обращается к библиотекам многократного использования для решения общих задач, но с инверсией контроля фреймворк вызывает пользовательский или специфический для задачи код. Инверсия контроля используется для повышения модульности программы и ее расширения и применяется в объектно-ориентированном программировании и других парадигмах программирования. Этот термин был использован Майклом Мэттссоном в диссертации, взятой оттуда Стефано Маццокки и популяризированной им в 1999 году в уже несуществ...

Внедрение зависимостей (dependency injection): примеры

Изображение
Пример без внедрения зависимости В следующем примере Java класс Client содержит переменную Service, которая инициализируется конструктором Client. Клиент контролирует, какая реализация сервиса используется, и контролирует его построение. В этой ситуации говорят, что клиент имеет жесткую зависимость от ExampleService. // Пример без внедрения зависимости public class Client { // внутренняя ссылка на сервис, // используемый этим клиентом private ExampleService service; // Конструктор Client() { // Указываем конкретную реализацию в конструкторе // вместо использования внедрения зависимости service = new ExampleService(); } // Метод в клиенте, который использует сервис public String greet() { return "Hello " + service.getName(); } } Внедрение зависимостей - это альтернативный метод инициализации переменной, вместо явного создания объекта service, как показано выше. Мы можем изменить этот пример, исполь...

Внедрение зависимостей (dependency injection)

Изображение
В программной инженерии внедрение зависимостей (dependency injection, DI) - это метод, при котором один объект предоставляет зависимости другого объекта. "Зависимость" - это объект, который можно использовать, например, в качестве сервиса. Вместо того, чтобы указывать клиенту, какой сервис он будет использовать, что-то говорит клиенту, какой сервис использовать. "Внедрение" относится к передаче зависимости (сервиса) в объект (клиент), который будет ее использовать. Сервис становится частью состояния клиента. Передача сервиса клиенту, а не предоставление клиенту возможности создавать или находить сервис, является фундаментальным требованием паттерна внедрение зависимостей. Внедрение зависимостей является порождающим (creational) паттерном проектирования. Цель внедрения зависимости заключается в разделении интересов при строительстве и использовании объектов. Это может улучшить читаемость и повторное использование кода. Внедрение зависимостей является одной из форм...