Ответ
Принцип разделения интерфейса (Interface Segregation Principle, ISP) — один из пяти SOLID-принципов. Он гласит, что клиенты не должны зависеть от методов интерфейсов, которые они не используют. Вместо одного «толстого» интерфейса следует создавать множество небольших, специфичных.
Проблема (нарушение ISP):
// Общий интерфейс, навязывающий ненужные методы
interface Worker {
void code();
void cook();
}
class Programmer implements Worker {
public void code() { /* Реализация */ }
public void cook() { // Программисту не нужно готовить
throw new UnsupportedOperationException();
}
}Решение (следование ISP):
// Специализированные интерфейсы
interface Coder {
void code();
}
interface Chef {
void cook();
}
class Programmer implements Coder {
public void code() { /* Только нужная функциональность */ }
}Преимущества:
- Уменьшение связности: Классы зависят только от необходимого функционала.
- Упрощение поддержки: Изменение одного интерфейса затрагивает меньше клиентов.
- Избегание «жирных» интерфейсов: Исключает пустые реализации или выброс исключений для неиспользуемых методов.
Ответ 18+ 🔞
Да ты посмотри на эту дичь, блядь! Опять эти ваши принципы, как будто без них мир рухнет. Ну ладно, слушай сюда, разберём эту хрень.
Вот представь, есть у тебя интерфейс Worker. И он такой всеобъемлющий, сука, универсальный солдат! «Работник» — и всё на свете должен уметь. Кодить? Пожалуйста! Готовить? Обязательно! Пол мыть? А как же, блядь!
interface Worker {
void code();
void cook();
}И вот ты, бедолага-программист, пытаешься этот интерфейс реализовать. Ну с code() всё ясно, это твоё. А cook()? А хуй его знает, как готовить! Приходится или пустой метод оставлять, или, что ещё позорнее, исключение кидать.
class Programmer implements Worker {
public void code() { /* Пишу код, а не шашлык */ }
public void cook() {
// Да я чай-то еле завариваю, блядь!
throw new UnsupportedOperationException("Иди нахуй, я не повар!");
}
}Вот это и есть та самая пиздец-ситуация, когда тебе навязывают то, что тебе нахуй не сдалось. Интерфейс превращается в этого толстого, блядь, неповоротливого монстра, который всем мешает.
А принцип-то ISP говорит простую, в общем-то, вещь: не заставляй клиента зависеть от того, что ему не нужно. Гениально и просто, как тапок по ебалу!
Вот как надо делать, по-человечески. Дробим этого жиробаса на нормальные, специализированные куски.
// Вот тебе интерфейс для тех, кто в теме с кодом
interface Coder {
void code();
}
// А вот — для кулинарных дел мастеров
interface Chef {
void cook();
}И теперь наш программист спокойно, без всякого стыда и совести, реализует только то, что ему надо.
class Programmer implements Coder {
public void code() { /* Да, я могу! И только это! */ }
}И что мы, сука, выигрываем?
- Связность меньше, голова болит реже. Класс тащит за собой только свою прямую ответственность, а не весь овердохуища бэклог компании.
- Поддерживать не ебёт мозг. Захотел поменять что-то в логике готовки — ты чинишь интерфейс
Chefи не трогаешь, блядь, пол-армии программистов, которым до печки как до луны. - Нет этих уродских
UnsupportedOperationException. Больше не нужно притворяться, что ты умеешь то, на что у тебя справки нет. Каждый делает своё дело и не ебёт других.
Короче, смысл в том, чтобы не создавать этих монструозных, всеядных интерфейсов. Лучше много маленьких и точных, чем один — на все случаи жизни, но от которого всем тошно. Прямо как в жизни, блядь: не пытайся быть мастером на все руки, а то окажешься, извини, хуй с горы — и там никому не нужен. Делай одну вещь, но делай её хорошо. Вот и весь ISP, ёпта.