# Nachteile objektorientierter Programmierung?



## bummerland (18. Sep 2003)

Was haltet ihr für Nachteile objektorientierter Programmierung?


----------



## DTR (18. Sep 2003)

Es soll am Anfang scher sein in das neue Denkverhalten einzuleben. Ich selbst kann das zwar nicht so nachvollziehen, aber bei anderen habe ich schon festgestellt, das Prozedural leichter zu verstehen ist.


----------



## stev.glasow (18. Sep 2003)

ist bei größeren sachen langsamer als das prozedurale.

und wenn du von einer klassen was erbst und die dann änderst musst du unter umständen die abgeleiteten klassen auch mit anpassen.


----------



## StarSeven (18. Sep 2003)

DTR hat gesagt.:
			
		

> Es soll am Anfang scher sein in das neue Denkverhalten einzuleben.


Aber es stimmt, ich selbst habe immer noch kleinere Probleme mit der objektorientierten Programmierung.


----------



## Nobody (18. Sep 2003)

-das ganze ist langsamer
-teilweise umständlicher als nicht oop
-benötigt mehr speicher
-teilweise längere programmierzeiten (man muss ja mehr schreiben)
-einstieg in die denkweise komplexer als bei der nicht oop variante


----------



## bummerland (19. Sep 2003)

Nobody hat gesagt.:
			
		

> -teilweise längere programmierzeiten (man muss ja mehr schreiben)



das gleicht sich aber dadurch wieder aus, dass man die erstellten klassen leicht wiederverwenden kann.


----------



## jptc.org (19. Sep 2003)

Nobody hat gesagt.:
			
		

> -einstieg in die denkweise komplexer als bei der nicht oop variante



Das kann so nicht stehen bleiben! Die OOP Denkweise ähnelt der menschlichen Denkweise mehr als die prozedurale! Ein Neueinsteiger in die Programmierung benötigt für OOP keinen Mehraufwand. Kritisch ist meist der Wechsel von prozedural zu OOP, da hier versucht wird irgendwie die alten Denkweisen im neuen Model wiederzufinden, was dann doch nicht funktioniert.

Karsten Voigt
http://www.java-performance-portal.org


----------



## Nobody (19. Sep 2003)

wenn jemand java lernt, muss er erstmal das grundsätzliche verstehen und das wird in der regel prozendual gemacht. => umdenken muss erfolgen (man sollte ja eine gewisse sicherheit haben um sich an grössere projekte zu wagen)

@becstift kann ich bedingt zu stimmen, kommt auf die komplexität des projektes an

@jptc also ich hab mich erhlich gesagt noch nie dabei erwischt, wie ich einem anderen teil meines gehirns parameter übergebe.
meine eselsbrücke für die leichtere umstellung ging/geht über das handhaben von methoden innerhalb einer klasse (besonders wenn man die rekursiven teile betrachtet) und im prinzip funktioniert das ganze so ähnlich mit der übergabe. das einzige was man dann noch beachten muss, ist der mögliche zugriff auf bestimmte werte und die korrekte rückgabe (und das man auch das bekommt was man braucht)


----------



## stev.glasow (20. Sep 2003)

Nobody hat gesagt.:
			
		

> @becstift kann ich bedingt zu stimmen, kommt auf die komplexität des projektes an



kanst du das mal erläutern ?


----------



## Nobody (20. Sep 2003)

schulprojekt: eine addressdatenbank anlegen. erst nicht oop dann später oop. die nicht oop variante war deutlich einfacher strukturiert und war etliche zeilen code weniger.


----------



## schalentier (20. Sep 2003)

oweia. sowas hab ich erwartet...

"oop is langsamer" - hä? wieso denn das? das kann man nicht globalisieren. eine software kann immer langsam oder schnell sein, das hat mit dem entwicklungsparadigma nix zu tun. 

"oop is umständlicher als nichoop" - bei kleineren sachen (insb. skripte) mag das stimmen, aber ab einer gewissen größe ist oop (korrekt angewendet) definitiv nicht umständlicher. 

"benötigt mehr speicher" - oop benötigt nicht grundsätzlich mehr speicher als nicht oop. das liegt an der sprache. allerdings ist der trend natürlich zu sehen, dass nahezu alle oop sprachen mehr speicher benötigen. aber speicher kostet heutzutage eh nix mehr.

"längere programmierzeiten" - hallo?? wer hat dir sowas in den kopf gesetzt? hast du jemals ein größeres projekt durchgeführt? oder noch besser, ein nicht oop projekt in den händen gehabt, weil die programmieren desselben einfach nicht mehr weiterkommen, da sie sich nicht mehr durch endloslange spagetticodetexte wurschteln KÖNNEN???

@stevg: wieso um himmels willen willst du eine oberklasse ändern? das macht man mit vererbung. dafür ist sie da. und wenn du wirklich was ändern willst (z.b. umbenennen), dann nimm ein vernünftiges refactoring tool (-->intelliJ) was änderungen an allen stellen vornimmt.
und wieso soll das ohne oop besser gehen? 



> also ich hab mich erhlich gesagt noch nie dabei erwischt, wie ich einem anderen teil meines gehirns parameter übergebe.
> meine eselsbrücke für die leichtere umstellung ging/geht über das handhaben von methoden innerhalb einer klasse (besonders wenn man die rekursiven teile betrachtet) und im prinzip funktioniert das ganze so ähnlich mit der übergabe. das einzige was man dann noch beachten muss, ist der mögliche zugriff auf bestimmte werte und die korrekte rückgabe (und das man auch das bekommt was man braucht)


hä? wovon redest du? gibts keine parameter in prozedural?

zum schulprojekt: 
was ist eine addressdatenbank? hat das eine gui? ich will mal eine prozedural geschriebene gui sehen . 
und wieso war es besser strukturiert, ohne oop? ich denke dann wurde ein fehler im design/entwurf gemacht. 
und wenn es dann auch noch mehr zeilen code hat, dann is da wirklich was schief gelaufen... 

will ja hier niemandem zu nahe treten oder dissen, aber wenn man keine ahnung hat, dann einfach mal den mund halten, mkay?

[/quote]


----------



## stev.glasow (9. Okt 2003)

:shock: das hab ich ja jetzt erst gelesen. und ihr wert euch nicht mal.




> @stevg: wieso um himmels willen willst du eine oberklasse ändern? das macht man mit vererbung. dafür ist sie da. und wenn du wirklich was ändern willst (z.b. umbenennen), dann nimm ein vernünftiges refactoring tool (-->intelliJ) was änderungen an allen stellen vornimmt.



das ändern was ich meinte und das für welches vererbung gedacht ist, haben kein bischen was mit einander zu tun! da kannst du so viel erben wie du willst - aber egal war vielleicht ein mißverständnis.

ein refactoring tool mag ein guten argument sein - aber es reicht nicht immer aus einfach die änderungen der oberklassen auf die unterklassen zu übertragen. es gibt auch oft fälle, in denen die logik einer oberklasse geändert werden muss so dass für die änderungen in den unterklassen logisches denken von nöten ist.




> "oop is langsamer" - hä? wieso denn das?


es wird allein dadurch schon etwas langsammer da der gesamt code in oop auf bedeutent mehr methoden aufgeteilt wird. und das mehr methodenaufrufe länger dauern ist ne tatsache, oder nicht?



> das kann man nicht globalisieren. eine software kann immer langsam oder schnell sein, das hat mit dem entwicklungsparadigma nix zu tun.


was meinst du mit  "eine software kann immer langsam oder schnell sein" ? das ist aus meiner sicht mehr als zweideutig.


----------



## Falke (10. Okt 2003)

Brauchen Programme die in Objektorienterter Sprache geschrieben wird mehr zeit zum planen, wegen den einzelnen verknüpfungen zwischen den Klassen ? Ich kenn mich damit nicht aus und finde es auch ziemlich schwer sich in die denkweise einzufinden.


----------



## Nobody (11. Okt 2003)

oh hab ich auch übersehen hatte wohl mal wieder keine zeit alle foren zu checken   

@schale ich antworte wenn ich mal die zeit dazu finde

@falke nein nicht wirklich, denn du kannst schon während des programmierens das ganze teilweise testen (geht bei prozedural zwar auch aber bei oop sieht man das deutlicher) indem du zb bestimmte methoden noch nicht erstellt hats sie aber schon funktionieren. wenn du für die planungein uml tool nutzt, kannst du dir das bei manchen sogar direkt in quellcode umwandeln lassen und dann musst du "nur noch" die methoden ausfüllen. die denkweise ist garnicht so komplex, man muss es nur 1 mal verstanden haben.

nun muss ich aber los


----------



## me.toString (13. Okt 2003)

Also für mich war der Einstieg in die OO-Welt einfach. Ich habe vorher noch nix weiter programmiert und habe dann im Studium mit Java angefangen. Als wir dann Java konnten [ mehr oder weniger ... was man halt so im 3. Semester kann ... ) ] haben die versucht uns C beizubringen. Ich fand das voll ätzend keine Objekte zu haben !!!

Und den Einwand, hinterher noch was an der Oberklasse zu ändern kann ich so nicht stehen lassen. Leute ... lernt mal vorher zu planen, und nicht einfach draufloszuhacken !!!!!
Für kleinste Projekte mag das gehen .. aber so bald mehrere an einem Projekt arbeiten ist die Planung unerlässlich !! Und in der OO-welt kann man nun mal besser planen [ UML ].
Wie macht ihr das bei eurem prozeduralen Zeugs denn, wenn sich z.B. die Signatur einer Methode ändert ? ... muss da nicht auch alles angepasst werden, was die Methode benutzt ???

Also ich muss jptc Recht geben wenn er sagt, dass die OO-denkweise dem menschlichen Denken viel nähr ist !! Wenn es in meinem Programm um Personen geht -> dann hab ich halt eine Klasse Person ... die Personen haben Eigenschaften -> die spiegeln sich in den Attributen meiner Klasse wieder ... die Personen können was machen -> das sind dann meine Methoden. 
Und wenn ich verschiedene Personentypen habe, dann werden das die unterklassen  [ bleiben dadurch aber weiterhin Personen ! ] ... also nähr kann man an das menschliche Denke doch gar nicht ran kommen !!!??

Aber was soll die Streiterei ? ... soll doch jeder programmieren, wie er [ sie ] es mag !!!

Michael


----------



## LastUnicorn (14. Jan 2004)

Naja die Objektorientierung hat es schon in sich. Da man nicht von links nach quer programmiert sollte man sich vorher erstmal einen Plan machen wie man vor geht. 

Es kommt sicher drauf an wann man OOP verwenden sollte. Wenn ich nur mal eben was schreiben will, was ich nicht lange brauche und was sonst kein anderer liesst, dann kann man sicher so coden wie man will. Arbeitet man aber an einem Projekt in dem mehrere Leute arbeiten oder das man sich des öfteren Ansehen muss, so zahlt sich die OOP auf jeden Fall aus, da das einlesen in den Code erheblich erleichtert wird und der Code weniger Fehleranfällig ist. Man muss halt kucken wann es sich lohnt mit OOP

Auf jeden Fall liesst sich OOP Code, wenn er richtig programmiert ist, sehr leicht...fast wie ein Buch


----------

