streamalism.org

1. Introduksjon

I denne opplæringen vil vi diskutere grensesnittets segregeringsprinsipp, et av SOLID-prinsippene. Å representere “jeg” i “SOLID”, betyr grensesnitt-segregering ganske enkelt at vi bør bryte større grensesnitt til mindre.

Dermed sikre at implementeringsklasser ikke trenger å implementere uønskede metoder.

2. Grensesnitt Segregeringsprinsipp

Dette prinsippet ble først definert av Robert C. Martin som: “Klienter bør ikke tvinges til å stole på grensesnitt de ikke bruker“.

Målet med dette prinsippet er å reduser bivirkningene ved å bruke større grensesnitt ved å dele applikasjonsgrensesnitt i mindre. Det ligner på prinsippet om enkelt ansvar, der hver klasse eller grensesnitt tjener et enkelt formål.

Nøyaktig applikasjonsdesign og riktig abstraksjon er nøkkelen bak grensesnittets segregeringsprinsipp. Selv om det vil ta mer tid og krefter i designfasen til en applikasjon og kan øke kodekompleksiteten, til slutt får vi en fleksibel kode.

Vi vil se på noen eksempler i de senere avsnittene der vi har brudd på prinsippet, og så løser vi problemet ved å bruke prinsippet riktig.

3. Eksempel på grensesnitt og implementering

La oss se på en situasjon der vi har en innbetaling grensesnitt som brukes av en implementering Bankbetaling:

offentlig grensesnitt Betaling {void initiatePayments (); Objektstatus (); Liste getPayments (); }

Og implementeringen:

offentlig klasse BankPayment implementerer betaling {@Override public void initiatePayments () {// ...} @Override public Object status () {// ...} @Override public List getPayments () {// ...}}

For enkelhets skyld, la oss ignorere den faktiske forretningsimplementeringen av disse metodene.

Dette er veldig tydelig - så langt implementeringsklassen Bankbetaling trenger alle metodene i innbetaling grensesnitt. Dermed bryter det ikke prinsippet.

4. Forurense grensesnittet

Nå som vi går fremover i tid, og flere funksjoner kommer inn, er det behov for å legge til en LånBetaling service. Denne tjenesten er også en slags innbetaling men har noen flere operasjoner.

For å utvikle denne nye funksjonen vil vi legge til de nye metodene i innbetaling grensesnitt:

offentlig grensesnitt Betaling {// originale metoder ... ugyldig intiateLoanSettlement (); ugyldig initiateRePayment (); }

Deretter får vi LånBetaling gjennomføring:

offentlig klasse LoanPayment implementerer Payment {@Override public void initiatePayments () {throw new UnsupportedOperationException ("This is not a bank payment"); } @Override public Object status () {// ...} @Override public List getPayments () {// ...} @Override public void intiateLoanSettlement () {// ...} @Override public void initiateRePayment () {// ...}}

Nå, siden innbetaling grensesnittet har endret seg og flere metoder ble lagt til, alle implementeringsklassene må nå implementere de nye metodene. Problemet er at implementering av dem er uønsket og kan føre til mange bivirkninger. Her, den LånBetaling implementeringsklassen må implementere initiatePayments () uten noe egentlig behov for dette. Og så er prinsippet brutt.

Så, hva skjer med vår Bankbetaling klasse:

offentlig klasse BankPayment implementerer betaling {@Override public void initiatePayments () {// ...} @Override public Object status () {// ...} @Override public List getPayments () {// ...} @Override public void intiateLoanSettlement () {throw new UnsupportedOperationException ("Dette er ikke en lånebetaling"); } @ Override public void initiateRePayment () {throw new UnsupportedOperationException ("Dette er ikke en lånebetaling"); }}

Merk at Bankbetaling implementering nå har implementert de nye metodene. Og siden det ikke trenger dem og ikke har noen logikk for dem, er det det bare kaster en Ikke-støttetOperationException. Det er her vi begynner å bryte med prinsippet.

I neste avsnitt vil vi se hvordan vi kan løse dette problemet.

5. Bruk av prinsippet

I den siste delen har vi med vilje forurenset grensesnittet og brutt prinsippet. I denne delen vil vi se på hvordan du legger til den nye funksjonen for betaling av lån uten å bryte med prinsippet.

La oss bryte ned grensesnittet for hver betalingstype. Den nåværende situasjonen:

Legg merke til i klassediagrammet, og med henvisning til grensesnittene i den tidligere delen, at status() og getPayments () metoder kreves i begge implementeringene. På den andre siden, initiatePayments () kreves bare i Bankbetaling, og initiateLoanSettlement () og initiateRePayment () metoder er bare for LånBetaling.

Med det sortert, la oss bryte opp grensesnittene og bruke prinsippet om segregering av grensesnitt. Dermed har vi nå et felles grensesnitt:

offentlig grensesnitt Betaling {Objektstatus (); Liste getPayments (); }

Og to grensesnitt til for de to typer betalingene:

offentlig grensesnitt Bank utvider betaling {void initiatePayments (); }

offentlig grensesnitt Lån utvider betaling {void intiateLoanSettlement (); ugyldig initiateRePayment (); }

Og de respektive implementeringene, og starter med Bankbetaling:

offentlig klasse BankPayment implementerer Bank {@Override public void initiatePayments () {// ...} @Override public Object status () {// ...} @Override public List getPayments () {// ...}}

Og til slutt, vår reviderte LånBetaling gjennomføring:

offentlig klasse LoanPayment implementerer lån {@Override public void intiateLoanSettlement () {// ...} @Override public void initiateRePayment () {// ...} @Override public Object status () {// ...} @Override offentlig liste getPayments () {// ...}}

La oss nå gjennomgå det nye klassediagrammet:

Som vi kan se, bryter grensesnittene ikke prinsippet. Implementeringene trenger ikke å gi tomme metoder. Dette holder koden ren og reduserer sjansen for feil.

6. Konklusjon

I denne opplæringen så vi på et enkelt scenario, der vi først avvek fra å følge Interface Segregation Principle og så problemene dette avviket forårsaket. Så viste vi hvordan man kan bruke prinsippet riktig for å unngå disse problemene.

Hvis vi har å gjøre med forurensede eldre grensesnitt som vi ikke kan endre, kan adaptermønsteret være nyttig.

Grensesnittets segregeringsprinsipp er et viktig konsept når du designer og utvikler applikasjoner. Å følge dette prinsippet bidrar til å unngå oppblåste grensesnitt med flere ansvarsoppgaver. Dette hjelper oss til slutt å følge prinsippet om enkelt ansvar.

Som alltid er koden tilgjengelig på GitHub.