Interface Segregation käytännössä
Soveltakaa Interface Segregation Principle -periaatetta pienien ja tarkasti kohdennettujen rajapintojen luomiseen ja välttäkää lihavia rajapintoja, jotka pakottavat asiakkaat riippumaan käyttämättömistä metodeista.
Interface Segregation käytännössä on ilmainen Clean Architecture ja suunnittelumallit käytännössä-oppitunti CoddyKitissä. Tämä on oppitunti 2/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Clean Architecture ja suunnittelumallit käytännössä-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Clean Architecture ja suunnittelumallit käytännössä-kurssilla on yhteensä 4 oppituntia.
Mikä ISP on?
Tervetuloa tutustumaan rajapintojen eriyttämisen periaatteeseen (ISP)! Tämä periaate on yksi olio-ohjelmoinnin suunnittelun viidestä SOLID-periaatteesta.
ISP:n ydinajatus on, että asiakkaita ei pidä pakottaa riippumaan rajapinnoista, joita ne eivät käytä. Yksinkertaisemmin sanottuna luokkia ei pidä pakottaa toteuttamaan metodeja, joita ne eivät tarvitse.
Ongelma: liian laajat rajapinnat
”Liian laaja rajapinta” on rajapinta, joka sisältää liian monta metodia, joista osa on sen toteuttaville luokille tarpeettomia.
Kun luokka toteuttaa liian laajan rajapinnan, sen on pakko tarjota toteutus kaikille metodeille, myös niille, joita se ei käytä. Tämä johtaa usein tyhjiin tai paikkamerkkinä toimiviin metodirunkoihin, mikä on koodihaju.
Esimerkki liian laajasta rajapinnasta
Tarkastellaan yleistä IWorker-rajapintaa. Ihmistyöntekijä saattaa suorittaa kaikki nämä toiminnot, mutta robottityöntekijä ei ehkä syö eikä nuku. Katsotaan, millaisia ongelmia tästä syntyy.
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
}
}Liian laajojen rajapintojen seuraukset
Kuten Robot-esimerkistä nähtiin, liian laajan rajapinnan toteuttaminen aiheuttaa useita ongelmia:
- Koodihajut: Tyhjät tai paikkamerkkinä toimivat metoditoteutukset.
- Hauras koodi: Rajapintaan tehdyt muutokset (esimerkiksi uuden metodin lisääminen) voivat pakottaa toisiinsa liittymättömät asiakkaat päivittämään koodiaan.
- Heikentynyt koossapysyvyys: Rajapinnalla on liikaa vastuita, joten sen kohdistus heikkenee.
- Kasvanut kytkentä: Asiakkaat ovat kytkeytyneet metodeihin, joita ne eivät käytä, mikä vaikeuttaa järjestelmän ylläpitoa ja testaamista.
Ratkaisu: rajapintojen eriyttäminen
Rajapintojen eriyttämisen periaate ehdottaa suurten, ”liian laajojen” rajapintojen jakamista pienemmiksi ja tarkemmin kohdistetuiksi rajapinnoiksi.
Kukin asiakas (luokka) toteuttaa tällöin vain oman vastuunsa kannalta olennaiset rajapinnat. Näin asiakkaita ei pakoteta riippumaan metodeista, joita ne eivät tarvitse.
ISP käytännössä: uudistettu koodi
Uudistetaan IWorker-esimerkkimme luomalla pienempiä, roolikohtaisia rajapintoja. Nyt kukin työntekijätyyppi voi toteuttaa vain sen, mitä se todella tarvitsee.
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!
}
}ISP:n käytön hyödyt
ISP:n soveltaminen tuo ohjelmistosuunnitteluun merkittäviä etuja:
- Parantunut koossapysyvyys: Rajapinnoista tulee tarkemmin kohdistettuja, ja ne edustavat yhtä selkeää vastuuta.
- Vähäisempi kytkentä: Asiakkaat riippuvat vain tarvitsemistaan metodeista, mikä vähentää kytkentää.
- Helpompi ylläpito: Yhteen rajapintaan tehdyt muutokset eivät vaikuta asiakkaisiin, jotka eivät toteuta sitä.
- Parempi testattavuus: Pienempiä ja tarkemmin kohdistettuja rajapintoja on helpompi simuloida ja testata erillään.
- Joustavuus: Uusia toimintoja voidaan lisätä luomalla uusia rajapintoja tai laajentamalla olemassa olevia pieniä rajapintoja vaikuttamatta nykyisiin asiakkaisiin.
ISP käytännössä
ISP on erityisen hyödyllinen järjestelmissä, joissa on erityyppisiä asiakkaita tai monimutkaisia toimintoja:
- Roolipohjaiset järjestelmät: Eri käyttäjäroolit (esimerkiksi ylläpitäjä, muokkaaja ja katselija) saattavat käyttää järjestelmän eri osia, jolloin kukin tarvitsee tietyn rajapinnan.
- API-suunnittelu: API-rajapintoja suunniteltaessa kannattaa tarjota eri asiakassovelluksille (esimerkiksi mobiili- ja verkkosovelluksille) omat päätepisteet tai rajapinnat.
- Liitännäisarkkitehtuurit: Liitännäiset voivat toteuttaa vain ne tietyt rajapinnat, jotka määrittelevät niiden pääsovellukselle tarjoamat toiminnot.
ISP ja SRP: nopea katsaus
Sekä ISP että vastuunjaon periaate (SRP) edistävät tarkasti kohdistettua suunnittelua, mutta ne toimivat eri tasoilla:
- SRP (Single Responsibility Principle): Keskittyy luokkiin ja määrittää, että luokalla pitäisi olla vain yksi syy muuttua.
- ISP (Interface Segregation Principle): Keskittyy rajapintoihin ja asiakkaisiin ja varmistaa, ettei asiakkaita pakoteta riippumaan metodeista, joita ne eivät käytä.
Ne toimivat usein yhdessä. SRP:n soveltaminen luokkiin voi luonnostaan johtaa selkeämpiin rajapintoihin, ja ISP:n soveltaminen voi auttaa luokkia noudattamaan paremmin SRP:tä, koska ne toteuttavat vain yhden vastuunsa kannalta olennaiset asiat.
Testatkaa ymmärrystänne
Kun käytettävissä on IDocumentProcessor-rajapinta, jonka metodit ovat printDocument(), scanDocument(), faxDocument() ja copyDocument(), mitkä seuraavista ovat hyviä tapoja soveltaa rajapintojen eriyttämisen periaatetta?
Oppitunnin yhteenveto
Hienoa työtä! Olette oppineet rajapintojen eriyttämisen periaatteen:
- Asiakkaita ei pidä pakottaa riippumaan rajapinnoista, joita ne eivät käytä.
- ”Liian laajat rajapinnat” johtavat tarpeettomiin metoditoteutuksiin ja hauraaseen koodiin.
- ISP ratkaisee tämän jakamalla suuret rajapinnat pienemmiksi ja asiakaskohtaisiksi rajapinnoiksi.
- Tämä parantaa koossapysyvyyttä, vähentää kytkentää ja tekee koodista helpommin ylläpidettävää ja testattavaa.
Muistakaa nämä periaatteet, kun suunnittelette vankempia ja joustavampia ohjelmistoja!
Opi Clean Architecture ja suunnittelumallit käytännössä tekoälytuutorin avulla — ilmaiseksi
Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.
- Kurssit
- 12
- Oppitunnit
- 48
Usein kysytyt kysymykset
Onko oppitunti ”Interface Segregation käytännössä” ilmainen?
Kyllä – oppitunnin ”Interface Segregation käytännössä” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Clean Architecture ja suunnittelumallit käytännössä-kurssin, päivitä CoddyKit PROhon. Clean Architecture ja suunnittelumallit käytännössä-kurssilla on yhteensä 4 oppituntia.
Mitä opin oppitunnilla ”Interface Segregation käytännössä”?
Soveltakaa Interface Segregation Principle -periaatetta pienien ja tarkasti kohdennettujen rajapintojen luomiseen ja välttäkää lihavia rajapintoja, jotka pakottavat asiakkaat riippumaan käyttämättömi… Harjoittelet Clean Architecture ja suunnittelumallit käytännössä-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.
Tarvitsenko kokemusta aloittaakseni Clean Architecture ja suunnittelumallit käytännössä-opiskelun?
Aiempi kokemus ei ole tarpeen. CoddyKitin Clean Architecture ja suunnittelumallit käytännössä-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 2/4.
Kuinka kauan ”Interface Segregation käytännössä”-oppitunnin suorittaminen kestää?
Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.
Voinko kirjoittaa ja suorittaa koodia tällä Clean Architecture ja suunnittelumallit käytännössä-oppitunnilla?
Kyllä. Jokainen Clean Architecture ja suunnittelumallit käytännössä-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.
Kaikki tämän kurssin oppitunnit
- Dependency Inversion -periaatteen syvällinen tarkastelu
- Interface Segregation käytännössä
- Refaktorointi suunnittelumalleilla
- Yhden vastuun periaatteen ja avoin–suljettu-periaatteen hallinta