Определение: Клиент не должен зависеть от интерфейсов, которые он не требует; Зависимость одного класса от другого должна быть установлена на самом маленьком интерфейсе.
Проблема возникает: класс A зависит от класса B через интерфейс I, а класс C зависит от класса D через интерфейс I. Если интерфейс I не является самым маленьким интерфейсом для класса A и класса B, то класс B и класс D должны реализовать методы, в которых они не нужны.
Решение: Разделите раздутый интерфейс I на несколько независимых интерфейсов, а класс A и класса C устанавливают зависимости с интерфейсами, которые им нужны соответственно. То есть принцип изоляции интерфейса принят.
Давайте приведем пример, чтобы проиллюстрировать принцип изоляции интерфейса:
Значение этого рисунка: класс A зависит от методов 1, метода 2, метода 3 в интерфейсе I, а класс B является реализацией зависимости от класса A. класса C, зависит от методов 1, метода 4, метода 5 в графике I, а класс D является реализацией зависимости от класса C. Для класса B и D, хотя они оба имеют не используемые методы (то есть методы, отмеченные красными фондами на рисунке), с тех пор, с тех пор, с тех пор.
Давайте сначала посмотрим на пример нарушения изоляции интерфейса:
Публичный интерфейс iWorker {public void work (); public void eat (); } public class Worker implements IWorker{ @Override public void work() { // TODO worker work} @Override public void eat() { // TODO worker eat} } public class Robot implements IWorker { @Override public void work() { // TODO robot work} @Override public void eat() { // TODO robot eat? }}
Поскольку роботам не нужно есть, Iworker считается раздутым интерфейсом. Конечно, вы также можете кратковременную реализацию метода EAT в классе роботов, но это может вызвать непредсказуемые ошибки. Например, если метод eat должен потреблять количество ланч -коробок, будет неверное явление.
Ниже приводится модифицированная реализация:
Публичный интерфейс iWorker {public void work (); } public interface Idiet {public void eat (); } Открытый класс Работник реализует iWorker, Idiet {@Override public void work () {// todo work} @override public void eat () {// todo work}} робот открытого класса.
Суммировать:
1. Интерфейс должен быть максимально небольшим и очень сплоченным, но он должен быть уместным и слишком подробным и трудным для поддержания.
2. Если он был спроектирован как раздутый интерфейс, он может быть изолирован с помощью режима адаптера.