Avatar billede kube Nybegynder
11. august 2007 - 12:18 Der er 7 kommentarer og
1 løsning

Dør det objekt orienterede koncept?

Hej

Har man helt glemt meningen med klasser og objekter?

Jeg skriver fordi, jeg føler man ikke benytter OOP og Java klasser  som sproget er designet til..

Jeg synes design patterns som session fascade benyttes for ofte selvom det ikke giver mening!

Fx hvis man har en bil, vil man ved OOP have en klasse ved navn Bil, der indeholdt variable og metoder. Men jeg ser ofte at man vælger at have objekter kun med properties og uden "funktionelle" metoder. Derimod har man så en "Business klasse" (CarBusiness fx) til at "styre" bilen. Dette synes jeg er overkill, og sender Java tilbage til struktureret programmering, som beskrevet her:
http://www.javaworld.com/javaworld/jw-04-2001/jw-0406-java101.html

Lad dog metoderne, der knytter sig til klassen Bil være i klassen Bil. Og kun hvis session fascade kan skabe et mere simpelt interface bør det benyttes, men dog stadig med metoder i selve Bil  klasen.

Er det MVC der har fået forkert indflydelse på Java programmering?

Hvad er Jeres holdning til dette, og hvordan vil I designe Jeres applikationer?
Avatar billede erikjacobsen Ekspert
11. august 2007 - 12:25 #1
Meget generelt:

1) Man kan programmere alt med proceduralt Pascal, anno 1975
2) OOP og design patterns gør det ikke muligt at programmere mere, men giver fleksibilitet og gør kode overskuelig
3) Man kan da sagtens "fylde" for mange design patterns på et problem, men det kommer jo an på de kriterier, der ligger til grund.
4) Jeg ser eksempler på noget der ligner "for mange" design patterns, men som giver mening i den kontekst de bruges, fx automatiske test, eller udskydelse af beslutning om implementationsdetaljer - det kan man ikke se, hvis man kun har den endelige kode.
Avatar billede arne_v Ekspert
11. august 2007 - 15:32 #2
Det objekt orienterede koncept dør ikke. Snarere tværtimod - det er så alment accepteret
idag at det er en selvfølge som derfor ikke nævnes.

Du har ret i at strengt OOP'sk skal en klasse have både properties og funktionalitet. Men OOP
er jo ikke det eneste design princip. Et andet design princip er opdeling i lag. Og når du skal
overføre objekter mellem lag, så er du nødt til at have en klasse med kun properties, fordi
funktionaliteten ikke skal drysses ud over flere lag.

Jeg tror såmænd ikke at MVC har noget med det at gøre. Jeg vil mene at det er en oversimplificering
at sige at M delen er en properties only del.
Avatar billede erikjacobsen Ekspert
11. august 2007 - 15:35 #3
Avatar billede kube Nybegynder
11. august 2007 - 18:52 #4
Men arne_v, du siger det er en oversimplificering at "model objekterne" kun er properties! Men fx i et DAO/DTO design pattern, der er DTO (data transfer objects) meget dumme objekter, og det er jo nærmest mere reglen end undtagelsen at man ser dette i webapplikationer..
Avatar billede kube Nybegynder
11. august 2007 - 18:53 #5
Vil I designe Jeres program, med en business klasse og et Bil objekt med properties. Eller ville I gøre det på den oprindelige OOP måde
Avatar billede arne_v Ekspert
12. august 2007 - 06:01 #6
DTO er jo netop beregnet til at overføre objekter mellem lag.
Avatar billede arne_v Ekspert
12. august 2007 - 06:04 #7
Hvis manager/service klassen har brug for at bruge andet end get/set af properties på
en bil, så bør den have en bil klasse med nogle metoder.

Men CRUD er ret almindeligt.
Avatar billede kube Nybegynder
14. august 2007 - 13:43 #8
luk
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Kurser inden for grundlæggende programmering

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester