God Interfaces: Anti-Pattern & Interface Segregation

Dieser Beitrag ist eine Begriffserklärung zum God Interface Anti-Pattern – inklusive Lösungsansätzen und Best Practices.

In a Nutshell

God Interfaces sind ein Designmuster in der Softwareentwicklung, das eine Klasse bereitstellt, die für viele andere Klassen zugänglich ist und alle notwendigen Funktionen zum Aufrufen von Bibliotheken oder Frameworks bietet.

Kompakte Fachbeschreibung

Ein God Interface ist ein Anti-Pattern, bei dem ein Interface zu viele Verantwortlichkeiten und Methoden hat. Es verletzt das Interface Segregation Principle (ISP) aus den SOLID-Prinzipien.

Probleme von God Interfaces:

• Zu viele Methoden: Interface wird unübersichtlich und schwer verständlich
• Hohe Kopplung: Implementierungen müssen unnötige Methoden implementieren
• Schlechte Wartbarkeit: Änderungen beeinflussen viele Implementierungen
• Verletzung von SRP: Ein Interface hat mehrere Gründe zur Änderung

Lösung durch Interface Segregation:

• Kleine, fokussierte Interfaces: Jedes Interface hat eine klare Verantwortlichkeit
• Client-spezifische Interfaces: Implementierungen müssen nur relevante Methoden implementieren
• Bessere Testbarkeit: Kleinere Interfaces sind einfacher zu mocken
• Geringere Kopplung: Änderungen beeinflussen nur betroffene Implementierungen

Prüfungsrelevante Stichpunkte

• God Interface: Interface mit zu vielen Verantwortlichkeiten
• Interface Segregation Principle: Clients sollten nicht gezwungen werden, Methoden zu implementieren, die sie nicht verwenden
• SOLID-Prinzipien: ISP ist Teil der SOLID-Prinzipien
• Anti-Pattern: God Interface ist ein häufiger Designfehler
• Wartbarkeit: Kleine Interfaces sind besser wartbar
• Kopplung: God Interfaces erhöhen die Kopplung unnötig
• IHK-relevant: Wichtig für Softwarearchitektur und -design

Kernkomponenten

1. God Interface: Ein Interface mit zu vielen Methoden/Verantwortlichkeiten
2. Interface Segregation: Aufteilung in kleine, fokussierte Interfaces
3. SOLID Principles: Sammlung von Design-Prinzipien
4. Single Responsibility Principle: Jede Klasse sollte eine Verantwortlichkeit haben
5. Dependency Inversion: Abhängigkeit von Abstraktionen, nicht Konkretionen
6. Client-Specific Interfaces: Interfaces zugeschnitten auf spezifische Anforderungen
7. Cohesion: Starke Beziehung zwischen Interface-Elementen
8. Coupling: Minimierung von Abhängigkeiten

Praxisbeispiele

God Interface (Anti-Pattern)

// SCHLECHT: God Interface mit zu vielen Verantwortlichkeiten
interface UserService {
    // Benutzer-Management
    User createUser(String username, String email);
    void deleteUser(Long userId);
    User updateUser(Long userId, User updates);
    User getUserById(Long userId);
    List<User> getAllUsers();
    
    // Authentifizierung
    boolean login(String username, String password);
    void logout(Long userId);
    boolean changePassword(Long userId, String oldPassword, String newPassword);
    
    // Berechtigungen
    void grantPermission(Long userId, String permission);
    void revokePermission(Long userId, String permission);
    boolean hasPermission(Long userId, String permission);
    
    // Benachrichtigungen
    void sendEmail(Long userId, String subject, String message);
    void sendSMS(Long userId, String message);
    
    // Logging
    void logUserAction(Long userId, String action);
    List<LogEntry> getUserLogs(Long userId);
}

Lösung durch Interface Segregation

// GUT: Kleine, fokussierte Interfaces

// Benutzer-Management
interface UserRepository {
    User create(User user);
    void delete(Long userId);
    User update(Long userId, User updates);
    User findById(Long userId);
    List<User> findAll();
}

// Authentifizierung
interface AuthenticationService {
    boolean authenticate(String username, String password);
    void logout(Long userId);
    boolean changePassword(Long userId, String oldPassword, String newPassword);
}

// Berechtigungen
interface AuthorizationService {
    void grant(Long userId, String permission);
    void revoke(Long userId, String permission);
    boolean hasPermission(Long userId, String permission);
}

// Benachrichtigungen
interface NotificationService {
    void sendEmail(Long userId, String subject, String message);
    void sendSMS(Long userId, String message);
}

// Logging
interface AuditService {
    void logUserAction(Long userId, String action);
    List<LogEntry> getUserLogs(Long userId);
}

// Implementierung benötigt nur relevante Interfaces
class UserServiceImpl implements UserRepository, AuthenticationService {
    private final UserRepository userRepo;
    private final PasswordEncoder passwordEncoder;
    
    // Nur relevante Methoden implementieren
    @Override
    public User create(User user) {
        return userRepo.create(user);
    }
    
    @Override
    public boolean authenticate(String username, String password) {
        User user = userRepo.findByUsername(username);
        return user != null && passwordEncoder.matches(password, user.getPassword());
    }
    
    // ... andere relevante Methoden
}

Client-Specific Interfaces

// Verschiedene Clients benötigen verschiedene Funktionalität

// Für Admin-Panel
interface AdminUserService {
    User createUser(String username, String email);
    void deleteUser(Long userId);
    List<User> getAllUsers();
}

// Für Login-System
interface LoginService {
    boolean authenticate(String username, String password);
    void logout(Long userId);
}

// Für Profil-Bearbeitung
interface ProfileService {
    User updateProfile(Long userId, ProfileUpdates updates);
    boolean changePassword(Long userId, String oldPassword, String newPassword);
}

// Jede Implementierung ist fokussiert und testbar
class AdminUserServiceImpl implements AdminUserService {
    private final UserRepository userRepository;
    private final AuditService auditService;
    
    @Override
    public User createUser(String username, String email) {
        User user = new User(username, email);
        User created = userRepository.create(user);
        auditService.logUserAction(created.getId(), "USER_CREATED");
        return created;
    }
}

Vorteile und Nachteile

Vorteile von Interface Segregation

• Bessere Wartbarkeit: Kleinere Interfaces sind einfacher zu ändern
• Geringere Kopplung: Implementierungen hängen nur von relevanten Interfaces ab
• Bessere Testbarkeit: Kleinere Interfaces sind einfacher zu mocken
• Klarere Verantwortlichkeiten: Jedes Interface hat einen klaren Zweck
• Flexibilität: Verschiedene Implementierungen für verschiedene Anforderungen

Nachteile von God Interfaces

• Hohe Komplexität: Zu viele Methoden machen Interfaces unübersichtlich
• Starke Kopplung: Implementierungen müssen unnötige Abhängigkeiten mitbringen
• Schlechte Testbarkeit: Große Interfaces sind schwer zu mocken
• Verletzungen von SOLID: Verletzt ISP und oft auch SRP

Best Practices

1. Interface Design Guidelines

// GUT: Interface mit klarem Zweck
interface EmailValidator {
    boolean isValid(String email);
    String normalize(String email);
}

// SCHLECHT: Interface mit mehreren Zwecken
interface ValidationService {
    boolean isValidEmail(String email);
    boolean isValidPhone(String phone);
    boolean isValidAddress(Address address);
    String normalizeEmail(String email);
    String normalizePhone(String phone);
}

2. Role-Based Interfaces

// Rollenbasierte Interfaces
interface Reader {
    String read();
}

interface Writer {
    void write(String content);
}

interface ReaderWriter extends Reader, Writer {
    // Kombiniert beide Rollen
}

3. Marker Interfaces

// Marker Interfaces für Typ-Sicherheit
interface Serializable { }
interface Cloneable { }
interface Remote { }

Häufige Prüfungsfragen

1. Was ist ein God Interface und warum ist es problematisch? Ein God Interface hat zu viele Verantwortlichkeiten und Methoden, was zu hoher Kopplung und schlechter Wartbarkeit führt.

2. Erklären Sie das Interface Segregation Principle! Clients sollten nicht gezwungen werden, Methoden zu implementieren, die sie nicht verwenden. Interfaces sollten klein und fokussiert sein.

3. Wie unterscheidet sich ISP von SRP? SRP bezieht sich auf Klassen (eine Verantwortlichkeit), ISP auf Interfaces (keine unnötigen Methoden).

4. Wann sind große Interfaces akzeptabel? Fast nie - wenn ein Interface zu groß wird, sollte es aufgeteilt werden.

Wichtigste Quellen

1. https://de.wikipedia.org/wiki/Interface_Segregation_Principle
2. https://refactoring.guru/design-patterns/interface-segregation
3. https://www.baeldung.com/java-interface-segregation-principle