Uygulamada Arayüz Ayrımı
Arayüz Ayrımı İlkesini uygulayarak yalın ve amaca özgü arayüzler oluşturun; istemcileri kullanmadıkları yöntemlere bağımlı bırakan şişkin arayüzlerden kaçının.
Uygulamada Arayüz Ayrımı, CoddyKit'te ücretsiz bir Clean Architecture & Design Patterns in Practice dersidir. Bu, 4 dersinin 2. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Clean Architecture & Design Patterns in Practice öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Clean Architecture & Design Patterns in Practice kursu toplamda 4 dersten oluşur.
Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.
What is ISP?
Welcome to the Interface Segregation Principle (ISP)! This principle is one of the five SOLID principles of object-oriented design.
At its core, ISP states that clients should not be forced to depend on interfaces they do not use. In simpler terms, don't make classes implement methods they don't need.
The Problem: Fat Interfaces
A 'fat interface' is an interface that contains too many methods, some of which are irrelevant to certain classes that implement it.
When a class implements a fat interface, it's forced to provide implementations for all methods, even those it doesn't use. This often leads to empty or placeholder method bodies, which is a code smell.
Fat Interface Example
Consider a general IWorker interface. While a human worker might perform all these actions, a robot worker might not eat or sleep. Let's see how this creates issues.
interface IWorker {
void work();
void eat();
void sleep();
void manageTeam();
}
class Robot implements IWorker {
@Override
public void work() {
System.out.println("Robot working...");
}
@Override
public void eat() {
// Robots don't eat, forced to implement
System.out.println("Robot can't eat.");
}
@Override
public void sleep() {
// Robots don't sleep, forced to implement
System.out.println("Robot can't sleep.");
}
@Override
public void manageTeam() {
// Not all robots manage teams
System.out.println("Robot can't manage team.");
}
}
public class Main {
public static void main(String[] args) {
Robot robot = new Robot();
robot.work();
robot.eat(); // This call is meaningless for a robot
}
}Consequences of Fat Interfaces
As seen with the Robot example, implementing a fat interface leads to several problems:
- Code Smells: Empty or placeholder method implementations.
- Brittle Code: Changes to an interface (e.g., adding a new method) might force unrelated clients to update their code.
- Reduced Cohesion: The interface has too many responsibilities, making it less focused.
- Increased Coupling: Clients are coupled to methods they don't use, making the system harder to maintain and test.
Solution: Segregating Interfaces
The Interface Segregation Principle proposes splitting large, 'fat' interfaces into smaller, more specific ones.
Each client (class) then only implements the interfaces that are relevant to its specific responsibilities. This ensures clients are not forced to depend on methods they don't need.
ISP in Action: Refactored Code
Let's refactor our IWorker example by creating smaller, role-specific interfaces. Now, each worker type can implement only what it truly needs.
interface IWorkable {
void work();
}
interface IEatable {
void eat();
}
interface ISleepable {
void sleep();
}
interface IManager extends IWorkable { // Managers also work
void manageTeam();
}
class HumanWorker implements IManager, IEatable, ISleepable {
@Override
public void work() { System.out.println("Human working..."); }
@Override
public void eat() { System.out.println("Human eating..."); }
@Override
public void sleep() { System.out.println("Human sleeping..."); }
@Override
public void manageTeam() { System.out.println("Human managing team..."); }
}
class RobotWorker implements IWorkable { // Only works
@Override
public void work() { System.out.println("Robot working..."); }
}
public class Main {
public static void main(String[] args) {
HumanWorker human = new HumanWorker();
human.work();
RobotWorker robot = new RobotWorker();
robot.work();
// robot.eat(); // This would now be a compile error, as expected!
}
}Benefits of Using ISP
Applying ISP brings significant advantages to your software design:
- Improved Cohesion: Interfaces become more focused and represent a single, clear responsibility.
- Reduced Coupling: Clients depend only on the specific methods they require, leading to looser coupling.
- Easier Maintenance: Changes to one interface don't impact clients that don't implement it.
- Better Testability: Smaller, focused interfaces are easier to mock and test in isolation.
- Flexibility: New functionalities can be added by creating new interfaces or extending existing small ones without affecting existing clients.
ISP in Practice
ISP is particularly useful in systems with diverse client types or complex functionalities:
- Role-Based Systems: Different user roles (e.g., Administrator, Editor, Viewer) might interact with different parts of a system, each needing a specific interface.
- API Design: When designing APIs, provide specific endpoints or interfaces for different client applications (e.g., mobile apps vs. web apps).
- Plugin Architectures: Plugins can implement only the specific interfaces that define the functionalities they provide to the main application.
ISP vs. SRP: A Quick Look
While both ISP and the Single Responsibility Principle (SRP) promote focused design, they operate at different levels:
- SRP (Single Responsibility Principle): Focuses on classes, stating a class should have only one reason to change.
- ISP (Interface Segregation Principle): Focuses on interfaces and clients, ensuring clients aren't forced to depend on methods they don't use.
They often work hand-in-hand. Applying SRP to classes might naturally lead to clearer interfaces, and applying ISP can help classes better adhere to SRP by only implementing what's truly relevant to their single responsibility.
Check Your Understanding
Given an interface IDocumentProcessor with methods printDocument(), scanDocument(), faxDocument(), and copyDocument(), which of the following are good ways to apply the Interface Segregation Principle?
Lesson Summary
Great job! You've learned about the Interface Segregation Principle:
- Clients should not be forced to depend on interfaces they do not use.
- 'Fat interfaces' lead to irrelevant method implementations and brittle code.
- ISP solves this by splitting large interfaces into smaller, client-specific ones.
- This improves cohesion, reduces coupling, and makes code more maintainable and testable.
Keep these principles in mind to design more robust and flexible software!
Sıkça Sorulan Sorular
“Uygulamada Arayüz Ayrımı” dersi ücretsiz mi?
Evet — “Uygulamada Arayüz Ayrımı” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Clean Architecture & Design Patterns in Practice kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Clean Architecture & Design Patterns in Practice kursu toplamda 4 dersten oluşur.
“Uygulamada Arayüz Ayrımı” dersinde ne öğreneceğim?
Arayüz Ayrımı İlkesini uygulayarak yalın ve amaca özgü arayüzler oluşturun; istemcileri kullanmadıkları yöntemlere bağımlı bırakan şişkin arayüzlerden kaçının. Clean Architecture & Design Patterns in Practice ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.
Clean Architecture & Design Patterns in Practice öğrenmeye başlamak için deneyim gerekli mi?
Önceden deneyim gerekmez. CoddyKit'te Clean Architecture & Design Patterns in Practice, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 2. dersidir.
“Uygulamada Arayüz Ayrımı” dersi ne kadar sürer?
Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.
Bu Clean Architecture & Design Patterns in Practice dersinde kod yazıp çalıştırabilir miyim?
Evet. Her Clean Architecture & Design Patterns in Practice dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.
Bu kursun tüm dersleri
- Bağımlılıkların Tersine Çevrilmesine Derinlemesine Bakış
- Uygulamada Arayüz Ayrımı
- Tasarım Kalıplarıyla Yeniden Düzenleme
- Tek Sorumluluk ve Açık-Kapalı İlkelerinde Ustalaşma