Modulares Programmieren vs. OOP

[jark]

Shade Of Mine schrieb:

TeeJay schrieb:

Als nächstes hab ich auch den Vorteil, das ich mir die Methodennamen nicht merken muß, da eine Anständige IDE eine Autovervollständigung hat, sobald man den Namen der Instanz und einen "." eingibt.
Alleine das finde ich schon sehr gut.

der geilste Grund warum man OOProgrammieren sollte

das ist doch bei der modularen programmierung auch so!

[Helium]

Als nächstes hab ich auch den Vorteil, das ich mir die Methodennamen nicht merken muß, da eine Anständige IDE eine Autovervollständigung hat, sobald man den Namen der Instanz und einen "." eingibt.
Alleine das finde ich schon sehr gut.

Pack halt alles in deinen Namespace. wenn du dann :: schreibst kommt das selbe.

[SpaceMonkey]

oop übersichtlicher? naja man muss sich halt im code zurechtfinden wie man das bewerkstelligt hängt von einem selbst ab
wenn du wissen willst was deine programme machen musst du auch wissen was in den methoden passiert.
ich beforzuge wie schon gesagt prozeduralprogrammierung da ich dann einfach an meinem projekt leicher feilen kann. muss nicht auf so belangloses wie ich darf auf dieses element nicht zugreifen weil es privat ist eingehen. vererbung ist fein und gut ist aber auch anderst leicht lösbar eben mit copypaste und ich sehe darin kein problem.
auch in büchern würde ich von oop abraten
für firmen könnte oop vielleicht interessant sein...

[Shade Of Mine]

SpaceMonkey schrieb:

vererbung ist fein und gut ist aber auch anderst leicht lösbar eben mit copypaste und ich sehe darin kein problem.

damit hat sich das Thema wohl erledigt - denn hier treffen 2 grundsätzlich verschiedene denkweisen aufeinander.

Wir wollen Code Redundanz vermeiden, so gut es geht - das ist IMHO eines der wichtigsten konzepte für wartbare programme.

und vererbung würde ich nun wirklich nicht mit copy&paste simulieren, sondern so:

struct Base
{
int i;
};

struct Derived
{
struct Base* base;
int j;
};

aber das ist ja auch ein OO-Ansatz.

Kann es sein, dass du dich noch nicht wirklich mit OOP auseinander gesetzt hast? Wenn du es schon getan hast und sagst: mag ich nicht, dann ist es OK. Aber für mich wirkt es irgendwie so, als ob du dich nicht damit beschäftigen willst und es vornherein für blöd hältst...

[SpaceMonkey]

ich will jetzt ganz sicher nicht die objektorientierte programmierung schlecht machen. hat sicher auch enorm viele vorteile besonders bei teamprogrammierung und wenn der aspekt wartbarkeit eine wichtige rolle spielt. aber oop muss nicht immer die erste wahl sein. wenn im moment der wartbarkeit oder der übersichtlichlichkeit keine bedeutung geschenkt wird und man allein an einem projekt arbeitet warum sollte man dann oo programmieren? würde ja nur zeit verschwenden...

[Shade Of Mine]

SpaceMonkey schrieb:

aber oop muss nicht immer die erste wahl sein.

Hat auch niemand behauptet. Nur deine Argumentation ist etwas schwammig.

Wann ist denn Wartbarkeit nicht wichtig? In meinen Augen ist es das immer.
Oder deine Argumentation über private Member...

wenn im moment der wartbarkeit oder der übersichtlichlichkeit keine bedeutung geschenkt wird und man allein an einem projekt arbeitet warum sollte man dann oo programmieren?

weil man mit OOP Sachen ausdrücken kann, die man ohne nicht kann (und umgekehrt natürlich auch)

Deshalb ist C++ ja eine Multiparadigmen Sprache - man kann OOP und Prozeduale Programme schreiben

würde ja nur zeit verschwenden...

wieso?
OOP hat doch keinen Mehraufwand - zumindest nicht generell. Sicher gibt es Sachen die man gerade zB Functional wesentlich eleganter und besser hinbekommt - aber generell sehe ich nirgends einen Mehraufwand.

[SpaceMonkey]

wartbarkeit darf meiner meinung nach nicht im mittelpunkt stehen.ich schreibe nicht ein programm um dafür gleich einen nachfolger programmieren zu müssen bin mit meinem programm jetzt beschäftigt und nicht mit der zukunft. es mag hier sicher projekte geben bei denen man an die zukunft denken muss warum auch an die zukunft denken ich bin ja schließlich mit meinem akutellen programm beschäftigtigt und mit keinem anderen.

ja es gibt sicher situationen in denen man mit oo besser aufgehoben ist. zum beispiel wenn man echt objekte hat die aufeinander aufbauen.
aber solch eine situation muss ja nicht immer gelten

oop kann einen schon einschrenken wenn man an einem problem arbeitet. warum sollte ich auch eine klasse definieren wenn es auch mit structs geht.
auch direkt einfach darauflosprogrammieren ist mit oop sicher schwerer

[Shade Of Mine]

sorry, aber kannst du auch Argumente bringen warum es mit OOP komplizierter ist, als ohne?

sicher - um unwartbaren spaghetti code zu schreiben, eignet sich prozeduale programmierung mehr, da man eher dazu verleitet wird.

erklär mal, was du an OOP nicht leiden kannst. mir ist es nicht ganz klar.

du sagst:
du brauchst keine wartbarkeit
du brauchst keine privaten-Elemente (dies bedeutet, dass du keine kapselung brauchst)
code redundanz ist egal für dich
sinnvolle strukturieren ist anscheinend auch egal (?)

wie steht es mit typensicherheit? abstraktion? und vorallem Fehlerfreien code (das stelle ich mir ohne gute struktur recht schwer zu realisieren vor)

erklär mal was für dich wichtig ist, vielleicht verstehe ich deine argumente dann besser...

PS: Ich behaupte nicht, dass OOP besser oder schlechter ist. ich will nur verstehen was du an OOP nicht magst.

[SpaceMonkey]

nein ich glaube du hast mich falsch verstanden. ich würde nicht wagen zu behaupten dass oop schlecht sei. ich will nur sagen dass es für mich einfach ein bisschen umständlich ist. so wenn ich jetzt zum beispiel ein paar variablen zusammenfassen und mit diesen variablen in meiner hauptschleife sehr viel spielen muss so müsste ich wenn ich oo programmieren würde eine klasse erzeugen die variablen die ich brauche in die klasse aufnehmen und um auf diese variablen zugreifen zu können müsste ich extra funktionen wie set_x(int _x) oder get_x() schreiben und das nur um auf die variable zugreifen zu können.
wenn ich jetzt nun in der hauptschleife mit diesen variablen berechnungen durchführen will müsste ich immer wieder die funktion get_x angeben um die variable x aus meiner klasse zu bekommen. das ist mir zum beispiel einfach zu umständlich und lege lieber ein struct an um dann direkt mit der variablen sprechen zu können.
klar ist diese art eher dreckig aber ich lege keinen wert auf schönheit des codes sondern die berechnungen in der hauptschleife sind mir wichtig und nicht das objektorientierte konzept. konzept soll ja schließlich einem helfen und nicht behindern.

[Shade Of Mine]

SpaceMonkey schrieb:

so wenn ich jetzt zum beispiel ein paar variablen zusammenfassen und mit diesen variablen in meiner hauptschleife sehr viel spielen muss so müsste ich wenn ich oo programmieren würde eine klasse erzeugen die variablen die ich brauche in die klasse aufnehmen und um auf diese variablen zugreifen zu können müsste ich extra funktionen wie set_x(int _x) oder get_x() schreiben und das nur um auf die variable zugreifen zu können.

OOP != alles in Klassen packen

Es spricht nichts dagegen diesen Loop genauso wie bisher zu machen. Nur uU representieren ein paar variablen gemeinsam ein Objekt, zB Spieler

Wenn du jetzt Spieler einen schritt nachvorne machen lassen willst, schreibst du statt

if(spieler_sicht==NACH_OBEN) ++spieler_y;
else if(spieler_sicht==NACH_UNTEN) --spieler_y;
else if(spieler_sicht==NACH_LINKS) --spieler_x;
else if(spieler_sicht==NACH_RECHTS) ++spieler_x;

einfach
spieler.moveForward();

es bedeutet aber nicht, dass alles einfach in klassen gepackt wird.

klar ist diese art eher dreckig aber ich lege keinen wert auf schönheit des codes sondern die berechnungen in der hauptschleife sind mir wichtig und nicht das objektorientierte konzept. konzept soll ja schließlich einem helfen und nicht behindern.

ich glaube ganz ehrlich, dass du dich noch nicht mit OOP auseinander gesetzt hast. zumindest hat nichts von dem was du gesagt hast so geklungen als hättest du dich länger ordentlich mit OOP befasst.

wenn dir OOP nicht liegt, oder du es nicht magst: kein Problem.
Aber dann erzähl auch nicht so sachen wie dass man 'extra ne methode schreiben um auf variablen zugreifen zu können' oder dass man mit structs flexibler ist (denn genau da hat dir Helium ja das gegenteil bewiesen - es sei denn du kapselst es schön in funktionen, dann kannst du einige c++ features simulieren, aber zB virtuelle methoden nicht) oder dass du von 'OOP in Büchern' abraten würdest...

wenn du OOP nicht magst: OK - aber bitte keinen quatsch erzählen (oder zumindest genau begründen)

[SpaceMonkey]

logisch was ist schöner?

if(spieler_sicht==NACH_OBEN) ++spieler_y;
else if(spieler_sicht==NACH_UNTEN) --spieler_y;
else if(spieler_sicht==NACH_LINKS) --spieler_x;
else if(spieler_sicht==NACH_RECHTS) ++spieler_x;

oder

spieler.moveForward();

frage?
angenommen dein spieler müsste vorwärts laufen aber es könnten vor ihm jede menge objekte liegen die ihn behindern. wie prüfst du jetzt in deiner funktion nach ob vor ihm ein objekt liegt?

[operator void]

In der OO-Variante würdest du das nur in Player::moveForward ändern. Ansonsten musst du jeden Code ändern, der direkt auf x/y zugreift. Das ist potenziell viel mehr.
Das heißt natürlich, dass Player von den anderen Objekten wissen muss. Solche "muss wissen von"s, die meistens mindestens eine Extra-Referenz bedeuten, sind meistens das, was mich zu structs treibt, die von eigentlich unbeteiligtem Code verarbeitet werden. Bei so wichtigen Objekten wie dem Spieler würde ich das aber nicht als Argument zählen lassen :p

[DrGreenthumb]

SpaceMonkey schrieb:

so wenn ich jetzt zum beispiel ein paar variablen zusammenfassen und mit diesen variablen in meiner hauptschleife sehr viel spielen muss
[...]
klar ist diese art eher dreckig aber ich lege keinen wert auf schönheit des codes sondern die berechnungen in der hauptschleife sind mir wichtig und nicht das objektorientierte konzept. konzept soll ja schließlich einem helfen und nicht behindern.

Und eine 200-Zeilen-Funktion mit fast globalen Variablen behindert nicht?!

Oh gott, ich hoffe der Code den du schreibst, verlässt niemals deine Festplatte...

[nman]

SpaceMonkey schrieb:

wartbarkeit darf meiner meinung nach nicht im mittelpunkt stehen.ich schreibe nicht ein programm um dafür gleich einen nachfolger programmieren zu müssen

Wartbarkeit heißt auch (IMO in erster Linie) vorhandene Bugs zu beseitigen etc und nicht in erster Linie auf den nächsten Major-Release zu schielen.

[Knuddlbaer]

operator void schrieb:

Das heißt natürlich, dass Player von den anderen Objekten wissen muss. Solche "muss wissen von"s, die meistens mindestens eine Extra-Referenz bedeuten, sind meistens das, was mich zu structs treibt, die von eigentlich unbeteiligtem Code verarbeitet werden. Bei so wichtigen Objekten wie dem Spieler würde ich das aber nicht als Argument zählen lassen :p

Generell muss Player aber nur von einer Basisklasse wissen. Danach kann es heute eine Wand sein gegen die ein Spieler läuft, aber morgen schon ein ganzes Haus. Du könntest z.B. der Wand gegen die der Spieler rennt den Spieler Übergeben und dafür sorgen das die Wand eine Methode kollision aufruft und sich selbst als Basisobjekt übergibt. Das machste bei Haus genauso, bei Hochhaus auch und bei Bretterbude ebenfalls. Ohne für die nachträglchen Häulse Spieler aber auch nur anfassen zu müssen.

Die Erfahrung die ich beim "Kampf" OOP VS Modulare Programmierung in der Firma gemacht habe ist, das sich keiner gedanken um das Projekt vor der Programmierung machen wollte. Lieber gleich loslegen, ohne Planung. Und dafür ist OOP nun mal nicht geeignet.

[Bashar]

Was soll an spieler.move_forward() so toll sein? In einer prozeduralen Welt wie C könnte man das gleiche durch player_move(&spieler) erledigen. Dass die Entscheidungslogik nicht an irgendeine beliebige Stelle gehört, sondern in eine eigene Funktion gehört, darauf sind schon andere vor der OOP gekommen.

An sich würde mich aber schon interessieren, ob irgendeiner von denen, die hier auf SpaceMonkey einschlagen, schonmal ein nicht-triviales Spiel programmiert hat, dass unter den Design-Maßstäben, die er hier im Thread anlegt, bestehen könnte. Ich würd dann gern den Source (oder UML oder was) dazu sehen, lerne nämlich gern dazu

[Shade Of Mine]

Bashar schrieb:

Was soll an spieler.move_forward() so toll sein? In einer prozeduralen Welt wie C könnte man das gleiche durch player_move(&spieler) erledigen.

Natürlich ist das egal. Mir ging es dabei eher darum die Kapselung zu erläutern.

Denn wir sind uns ja wohl einig dass eine Move-Funktion wichtig ist - um Objekte zu bewegen und dass man nicht direkt die x und y Werte des Objektes ändern sollte, oder?

Genau das wollte ich zeigen - schließlich geht es hier nicht um OOP vs Prozedualer Programmierung, sondern so wie ich SpaceMonkey verstanden habe - hat er keine struktur in seinem code.

Ich hoffe auch, dasss wir uns einig sind, dass es egal ist ob man OO, Prozedual, Funktional oder sonstwas programmiert - da generell alle Methoden Sinn machen (Ausnahme: spezielle Probleme, fordern spezielle Lösungen)

[SpaceMonkey]

programmteile die öfter vorkommen in funktionen zu packen mag sicher sinnvoll sein aber das ist ja hier nie zum thema gestanden oder? die x und y werte nie direkt ändern ist ja das konzept der oop manchmal kann es eben aber auch ganz nett sein wenn man x und y werte der klasse/struct direkt ändern kann besonders eben bei solchen problemen wie kollision oder wenn mehrere spieler gegeneinander laufen. klar mit oop könnte man das sicher auch lösen aber ich will das problem eben direkt angehen und keine klassen erzeugen. für manche hier mag das mit den klassen sicher einfacher und übersichtlicher sein ich will aber direkt mit den werten spielen und wenn teile öfter vorkommen pack ich den code dann in funktionen. zum beispiel initspieler um startwerte zu setzen oder eben zum beispiel die movefunktion. aber eben das ergebnis oop und prozedural ist das gleiche.
struktur in seinen code zu bekommen kann man auch später erledigen jeder hat eben eine andere arbeitstechnik aber ich bastle eben einfach herum schreibe in meiner hauptschleife füge oben wenn nötig funktionen hinzu und später kann ich das ganze dann in dateien packen. andere schauen hier gleich auf struktur ich eben nicht. jeder wie er will

[lol]

ich glaube es lohnt sich nicht mit SpaceMonkey weiter zu diskutieren.

[SpaceMonkey]

ist richtig