Hvorfor bruker en klasse som en struct dårlig praksis i Java?

stemmer
13

Vi har nylig hatt en kode gjennomgang. En av mine klasser ble brukt slik at jeg kunne gå tilbake / passere mer enn én type data fra / til metoder. De eneste metoder som klassen hadde var kundeskaffere / settere. En av lagets medlemmer (som mener jeg respekterer) sa at det å ha en klasse som det er dårlig praksis (og ikke veldig OOP). Hvorfor det ?

Publisert på 23/11/2008 klokken 18:14
kilden bruker
På andre språk...                            


6 svar

stemmer
14

Det er et argument at klassene skal enten være "datastrukturer" (dvs. fokus på lagring av data med ingen funksjonalitet) eller "funksjonalitet orientert" (dvs. fokusere på å utføre visse handlinger mens lagring minimal stat). Hvis du følger dette argumentet (som er fornuftig, men er ikke alltid lett å gjøre) så er det ingenting nødvendigvis galt med det.

Faktisk vil man hevde at bønner og enhets-bønner er i hovedsak at - lagringsbeholdere med getter og settere.

Jeg har sett enkelte kilder (for eksempel boken "ren code") hevder at man bør unngå metoder med flere parametere, og i stedet passere dem som et enkelt objekt med getter og settere. Dette er også nærmere "smalltalk modell" av navngitte parametere der for ikke spiller noen rolle.

Så jeg tror at når det brukes riktig, ditt motiv er fornuftig.

Svarte 23/11/2008 kl. 18:25
kilden bruker

stemmer
4

Legg merke til at det er to separate saker her.

  1. Er en "struct-lignende" class fornuftig?

  2. Er å skape en klasse for å returnere flere verdier fra en metode fornuftig?

Struct-lignende klasser

Et objekt klasse bør - for det meste - representerer en klasse av reelle stedene. En passiv, struct-lignende java bønne (alle kundeskaffere og settere) kan representere en reell ting.

Men de fleste virkelige ting har regler, begrensninger, atferd og grunnleggende verb der de deltar. En struct-lignende klassen er sjelden en god match for en reell ting, det er som regel noen tekniske ting. Det gjør det mindre enn ideell OO design.

Flere returnerer fra en metode

Mens Python har dette, gjør Java ikke. Flere returverdier er ikke en OO spørsmålet, per se . Det er et spørsmål om å jobbe gjennom språk begrensninger.

Flere returverdier kan bety at et objekt har endret tilstand. Kanskje er én metode endrer tilstanden og noen gruppe av getter returnerer verdier som stammer fra denne tilstandsendring.

Svarte 23/11/2008 kl. 19:43
kilden bruker

stemmer
3

For å være ærlig, det høres greit for meg. Hvilke alternative gjorde anmelderen foreslå?

Etter OOP "beste praksis" og alt er fint, men du er nødt til å være pragmatisk og faktisk få jobben gjort.

Bruke Verdi Objekter som dette (OO taler for 'struct') er en helt legitim tilnærming i noen tilfeller.

Svarte 23/11/2008 kl. 22:22
kilden bruker

stemmer
1

Generelt, vil du ønsker å isolere den kunnskapen som trengs for å operere på en klasse i klassen selv. Hvis du har en klasse som dette, enten den brukes på flere steder, og dermed kan ta på noen av funksjonaliteten i begge disse stedene, eller det er på ett sted, og bør være en indre klasse. Hvis den brukes på flere måter, men på helt forskjellige måter, slik at det ikke er noen felles funksjonalitet, har det være en enkelt klasse er misvisende, noe som indikerer en felles funksjonalitet der det er ingen.

Men det er ofte spesielle grunner for hvor disse generelle reglene kan eller ikke kan bruke, så det avhenger av hva klassen skulle representere.

Svarte 23/11/2008 kl. 18:23
kilden bruker

stemmer
0

Kanskje Josh Bloch har noen innsikt i dette her .

Svarte 23/11/2008 kl. 18:56
kilden bruker

stemmer
0

Jeg tror han kan være forvirrende "ikke veldig OOP" for dårlig praksis. Jeg tror han forventet å gi flere metoder som ville hvert returnerer en verdi som var nødvendig (som du er nødt til å bruke dem i den nye klassen likevel det er ikke så ille).

Merk at i dette tilfellet har du sannsynligvis ikke bør bruke getters / settere, bare gjøre data offentlig. Nei dette er "ikke veldig OOP", men er den rette måten å gjøre det.

Svarte 23/11/2008 kl. 18:30
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more