Interface Segregation i praksis
Anvend Interface Segregation Principle til at oprette smalle, specifikke grænseflader og undgå brede grænseflader, der tvinger klienter til at afhænge af metoder, de ikke bruger.
Interface Segregation i praksis er en gratis Ren arkitektur og designmønstre i praksis-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Ren arkitektur og designmønstre i praksis, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Ren arkitektur og designmønstre i praksis-kurset indeholder 4 lektioner i alt.
Hvad er ISP?
Velkommen til princippet om grænsefladeopdeling (ISP)! Dette princip er ét af de fem SOLID-principper for objektorienteret design.
Kernen i ISP er, at klienter ikke bør tvinges til at afhænge af grænseflader, de ikke bruger. Sagt enklere: Lad ikke klasser implementere metoder, de ikke har brug for.
Problemet: Fede grænseflader
En "fed grænseflade" er en grænseflade, der indeholder for mange metoder, hvoraf nogle er irrelevante for bestemte klasser, der implementerer den.
Når en klasse implementerer en fed grænseflade, tvinges den til at levere implementeringer af alle metoder, også dem den ikke bruger. Det fører ofte til tomme metodekroppe eller pladsholder-metodekroppe, hvilket er et tegn på dårlig kode.
Eksempel på en fed grænseflade
Forestil dig den generelle grænseflade IWorker. En menneskelig medarbejder udfører måske alle disse handlinger, men en robotmedarbejder spiser eller sover måske ikke. Lad os se, hvordan det skaber problemer.
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
}
}Konsekvenser af fede grænseflader
Som eksemplet med Robot viser, fører implementering af en fed grænseflade til flere problemer:
- Tegn på dårlig kode: Tomme metodeimplementeringer eller pladsholderimplementeringer.
- Skrøbelig kode: Ændringer i en grænseflade (f.eks. tilføjelse af en ny metode) kan tvinge irrelevante klienter til at opdatere deres kode.
- Lavere sammenhæng: Grænsefladen har for mange ansvarsområder og bliver dermed mindre fokuseret.
- Øget kobling: Klienter er koblet til metoder, de ikke bruger, hvilket gør systemet sværere at vedligeholde og teste.
Løsningen: Opdeling af grænseflader
Princippet om grænsefladeopdeling foreslår at dele store, "fede" grænseflader op i mindre og mere specifikke grænseflader.
Hver klient (klasse) implementerer derefter kun de grænseflader, der er relevante for dens specifikke ansvarsområder. Det sikrer, at klienter ikke tvinges til at afhænge af metoder, de ikke har brug for.
ISP i praksis: Omstruktureret kode
Lad os omstrukturere vores eksempel med IWorker ved at oprette mindre, rollebaserede grænseflader. Nu kan hver medarbejdertype kun implementere det, den reelt har brug for.
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!
}
}Fordele ved at bruge ISP
Anvendelse af ISP giver betydelige fordele for din softwareudformning:
- Bedre sammenhæng: Grænseflader bliver mere fokuserede og repræsenterer ét enkelt, tydeligt ansvarsområde.
- Mindre kobling: Klienter afhænger kun af de specifikke metoder, de har brug for, hvilket fører til løsere kobling.
- Nemmere vedligeholdelse: Ændringer i én grænseflade påvirker ikke klienter, der ikke implementerer den.
- Bedre testbarhed: Mindre, fokuserede grænseflader er nemmere at efterligne og teste isoleret.
- Fleksibilitet: Nye funktioner kan tilføjes ved at oprette nye grænseflader eller udvide eksisterende små grænseflader uden at påvirke eksisterende klienter.
ISP i praksis
ISP er særligt nyttigt i systemer med forskellige klienttyper eller komplekse funktioner:
- Rollebaserede systemer: Forskellige brugerroller (f.eks. administrator, redaktør og læser) interagerer måske med forskellige dele af et system, hvor hver rolle har brug for en specifik grænseflade.
- API-udformning: Når du udformer API'er, skal du levere specifikke slutpunkter eller grænseflader til forskellige klientapplikationer (f.eks. mobilapps kontra webapps).
- Plugin-arkitekturer: Plugins kan kun implementere de specifikke grænseflader, der definerer de funktioner, de leverer til hovedapplikationen.
ISP kontra SRP: Et hurtigt overblik
Selvom både ISP og princippet om enkelt ansvar (SRP) fremmer en fokuseret udformning, arbejder de på forskellige niveauer:
- SRP (princippet om enkelt ansvar): Fokuserer på klasser og fastslår, at en klasse kun bør have én grund til at ændre sig.
- ISP (princippet om grænsefladeopdeling): Fokuserer på grænseflader og klienter og sikrer, at klienter ikke tvinges til at afhænge af metoder, de ikke bruger.
De fungerer ofte sammen. Anvendelse af SRP på klasser kan naturligt føre til tydeligere grænseflader, og anvendelse af ISP kan hjælpe klasser med bedre at overholde SRP, fordi de kun implementerer det, der reelt er relevant for deres ene ansvarsområde.
Test din forståelse
Du har en grænseflade IDocumentProcessor med metoderne printDocument(), scanDocument(), faxDocument() og copyDocument(). Hvilke af følgende er gode måder at anvende princippet om grænsefladeopdeling på?
Opsummering af lektionen
Flot arbejde! Du har lært om princippet om grænsefladeopdeling:
- Klienter bør ikke tvinges til at afhænge af grænseflader, de ikke bruger.
- "Fede grænseflader" fører til irrelevante metodeimplementeringer og skrøbelig kode.
- ISP løser dette ved at dele store grænseflader op i mindre, klientspecifikke grænseflader.
- Det forbedrer sammenhængen, reducerer koblingen og gør koden nemmere at vedligeholde og teste.
Husk disse principper, når du vil udforme mere robust og fleksibel software!
Lær Ren arkitektur og designmønstre i praksis med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 12
- Lektioner
- 48
Ofte stillede spørgsmål
Er lektionen “Interface Segregation i praksis” gratis?
Ja — hele teksten til “Interface Segregation i praksis” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Ren arkitektur og designmønstre i praksis-kurset, skal du opgradere til CoddyKit PRO. Ren arkitektur og designmønstre i praksis-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Interface Segregation i praksis”?
Anvend Interface Segregation Principle til at oprette smalle, specifikke grænseflader og undgå brede grænseflader, der tvinger klienter til at afhænge af metoder, de ikke bruger. Du øver dig i Ren arkitektur og designmønstre i praksis med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Ren arkitektur og designmønstre i praksis?
Der kræves ingen tidligere erfaring. Ren arkitektur og designmønstre i praksis på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.
Hvor lang tid tager lektionen “Interface Segregation i praksis”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Ren arkitektur og designmønstre i praksis-lektion?
Ja. Alle Ren arkitektur og designmønstre i praksis-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Fordybelse i Dependency Inversion
- Interface Segregation i praksis
- Refaktorering med design patterns
- Mesterskab i Single Responsibility og Open-Closed