Konstant grænseflade

I programmeringssproget Java, den konstante grænseflade mønster beskriver anvendelsen af ​​en grænseflade udelukkende at definere konstanter, og som har klasser implementere denne grænseflade for at opnå praktisk syntaktisk adgang til disse konstanter. Men da konstanter er meget ofte blot en detalje implementering og grænseflader, der gennemføres af en klasse er en del af dens eksporterede API, beløber denne praksis til at sætte implementeringer oplysninger i API, hvilket blev anset for upassende af bl.a. Java designer Joshua Bloch. Generelt kan kloaknet konstanter i klasser uafhængigt af adfærd til at skabe en dårlig objektorienteret design, fordi det ofte er et tegn på lav sammenhængskraft. Det er af disse grunde, gennemførelsesbestemmelser konstanter grænseflader kan anses for at være en anti-mønster.

Anvendelse af dette mønster har et par andre ulemper:

  • Det forurener klassen namespace med read-only variabler, måske ikke er brug.
  • I modsætning til compile-time taktisk nytten af ​​at gennemføre en konstanter interface, tilfældige køre-time artefakter har ringe praktisk formål.
  • Hvis binær kode kompatibilitet er påkrævet i fremtidige udgivelser, skal konstanter grænseflade altid forblive en grænseflade, selv om det ikke har været brugt som en grænseflade i traditionel forstand.
  • Uden en IDE, der løser hvor konstanten kommer fra, spore det tilbage til dets indhold af klasse eller grænseflade kan være tidskrævende.
  • En variabel af grænsefladen er syntaktisk ikke mere nyttigt end grænsefladenavnet selv.

Bemærk, at Java bibliotekerne bruge konstant grænseflade mønster selv, beviser, at det kan være et rimeligt valg i nogle situationer.

Eksempel

Alternativer

Mange af de faldgruber af anti-mønster kan undgås ved at konvertere konstanter interface til en ordentlig klasse med nogen tilfælde:

Dette efterlader stadig den oprindelige hensigt med mønstret meste un-behandlet. Men da Java 5, overveje at bruge statisk import til at nå det samme mål:

Konstanterne kan også importeres massevis ved at tilføje en import statiske konstanter. * Erklæring. Dette opnår de samme mål som at bruge en grænseflade, der giver de konstanter, der skal refereres uden namespace.

I varierende grad, har de spørgsmål, der er anført ovenfor nu løst:

  • Fordi statiske medlemmer kan importeres specifikt behøver klassen navnerummet ikke forurenet med alle medlemmer af konstanter interface.
  • Run-time og kompilere-tid semantik er tættere knyttet ved brug af statiske import i stedet for konstanter grænseflader.
  • Den kompileret kode har en mindre binær kompatibilitet tvang.
  • Fordi statiske import gælder kun for den aktuelle fil er det lettere at opdage, hvor hver statisk medlem deklareres.
  • Der er mindre behov for at erklære variable af konstanter interface type, og det er potentielt mere klart, at ingen konkrete tilfælde faktisk eksisterer.

Bemærk dog, ændringerne ikke gøre noget for at forbedre sammenhængen i Konstanter klassen, så statiske import bør ikke betragtes som et universalmiddel.

  0   0
Forrige artikel Bob Tallman
Næste artikel Albert Ernest Radford

Kommentarer - 0

Ingen kommentar

Tilføj en kommentar

smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile smile smile smile smile
smile smile smile smile
Tegn tilbage: 3000
captcha