Принцип розділення інтерфейсу

SOLID
принципи об'єктно-орієнтованого проєктування
Принцип єдиної відповідальності Принцип відкритості/закритості Принцип підстановки Лісков Принцип розділення інтерфейсу Принцип інверсії залежностей

Принцип розділення інтерфейсу (англ. Interface Segregation Principle, ISP) — важливий принцип об'єктно-орієнтованого програмування, визначений Робертом Мартіном у такому вигляді:

Клієнти не повинні залежати від методів, які вони не використовують. Оригінальний текст (англ.) The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

Отже, даний принцип означає, що занадто «товсті» інтерфейси необхідно розділяти на менші та специфічні, щоб їх клієнти знали лише про ті методи, що необхідні для них у роботі. Як результат, при зміні певного функціоналу, незмінними мають лишитися ті класи, що не використовують його. Тобто виконання цього принципу допомагає системі залишатися гнучкою при внесенні до неї змін та лишатися простою для рефакторингу.

Приклад

Приклад порушення ISP

Для прикладу порушення уявімо собі таку систему:

public interface Animal {
	void eat();
	void fly();
	void bark();
}

public class Bird implements Animal {
	@Override
	public void eat() {
		// деяка реалізація
	}
	
	@Override
	public void fly() {
		// деяка реалізація
	}
	
	@Override
	public void bark() {
		throw new UnsupportedOperationException();
	}
}

public class Dog implements Animal {
	@Override
	public void eat() {
		// деяка реалізація
	}
	
	@Override
	public void fly() {
		throw new UnsupportedOperationException();
	}
	
	@Override
	public void bark() {
		// деяка реалізація
	}
}

Що буде, коли в систему доведеться додавати новий клас, наприклад Cat? Легко здогадатися, якою буде його реалізація.

Застосування ISP

Виходом з цієї ситуації є використання розділення інтерфейсу. Так званий «товстий» Animal варто розділити на наступні два інтерфейси: Flyable та Barkable.

public interface Animal {
	void eat();
}

public interface Flyable {
	void fly();
}

public interface Barkable {
	void bark();
}

public class Bird implements Animal, Flyable {
	@Override
	public void eat() {
		// деяка реалізація
	}
	
	@Override
	public void fly() {
		// деяка реалізація
	}
}

public class Dog implements Animal, Barkable {
	@Override
	public void eat() {
		// деяка реалізація
	}
	
	@Override
	public void bark() {
		// деяка реалізація
	}
}

Після застосування такого підходу класи стають «здоровими», з них зникають зайві методи.

ISP та шаблони проектування

Проте інколи складається ситуація, що не дозволяє зробити такий рефакторинг. Тоді варто застосовувати архітектурне рішення, що надає паттерн Адаптер. Система набуває такого вигляду:

public interface Animal {
	void eat();
	void fly();
	void bark();
}

public interface Eatable {
	void eat();
}

public interface Flyable {
	void fly();
}

public interface Barkable {
	void bark();
}

public class FlyingAdapter implements Eatable, Flyable {
	private Animal animal;
	
	public FlyingAdapter(Animal animal) {
		this.animal = animal;
	}
	
	@Override
	public void fly() {
		animal.fly();
	}
	
	@Override
	public void eat() {
		animal.eat();
	}
}

public class BarkingAdapter implements Eatable, Barkable {
	private Animal animal;
	
	public BarkingAdapter(Animal animal) {
		this.animal = animal;
	}
	
	@Override
	public void bark() {
		animal.bark();
	}
	
	@Override
	public void eat() {
		animal.eat();
	}
}

Наслідки використання цього підходу наступні:

• клієнтський код працює лише з тією функціональністю, яка йому потрібна;
• в той же час, робота відбувається за допомогою сутностей старої системи, що не вимагає в ній будь-яких змін;
• подібний підхід знижує очевидність архітектурних рішень, прочитність коду, і має використовуватись тільки якщо зміна старої системи неможлива з певних причин.

Переваги та недоліки

Серед плюсів варто відзначити наступні:

• при необхідності створення нової реалізації інтерфейсу немає потреби реалізовувати непотрібні методи;
• клієнтський код отримує лише те, що потрібне для його роботи.

Мінус використання полягає в зростанні кількості інтерфейсів, що приводить до зростання складності системи.

Використання

SOLID — буква «I» означає принцип розділення інтерфейсу (англ. Interface Segregation Principle).

Посилання

• OOP SOLID Rules : Interface Segregation Principle (ISP) [Архівовано 23 березня 2013 у Wayback Machine.] (англ.)
• SOLID conclusions with ISP and DIP [Архівовано 14 січня 2014 у Wayback Machine.] (англ.)
• Принцип разделения интерфейса [Архівовано 21 травня 2013 у Wayback Machine.] (рос.)
• OOD Principles (рос.)