3. Modulares Programmieren vs. OOP

Modulares Programmieren vs. OOP

  • H

    Was ist eigentlich besser: Brot oder Nudeln?

    0
  • K

    Helium schrieb:

    Was ist eigentlich besser: Brot oder Nudeln?

    Dafür solltest du schon deinen eigenen Thread aufmachen, sonst wird das hier noch zu unübersichtlich 😉

    0
  • S

    ich bevorzuge prozedural denn ich hab möchte "direkt" programmieren und habe keine lust extra eine methode zu schreiben um auf meine variablen zugreifen zu können. mit oop ist man viel länger am programmieren und ist nicht direkt mit dem problem konfrontiert. auch für lehrbücher finde ich oop nicht geeignet. wenn ein autor zum beispiel in 3d spieleprogrammierung das kompendium von stefan zerbst eine objektorientierte programmierung verwendet, muss man sich zuerst damit beschäftigen wie er die klasse aufgebaut hat anstatt dass man gleich den code sehen kann den einen interessiert!

    meine meinung natürlich kann ich mich auch täuschen. viele sind sicher anderer meinung ich programmiere prozedural

    0
  • H

    ich bevorzuge prozedural denn ich hab möchte "direkt" programmieren und habe keine lust extra eine methode zu schreiben um auf meine variablen zugreifen zu können. mit oop ist man viel länger am programmieren und ist nicht direkt mit dem problem konfrontiert.

    Du machst offensichtlich was grundlegendes falsch.

    Folgendes: Ein Spiel. Es gibt Gegner. Also eine abstrakte Klasse Gegner. Davon leitest du verschiedene Monster, Soldaten oder was auch immer ab. und das in zwei Schwierigkeitsstufen. Die leichtere Schtufe ist einfach etwas dümmer. Was weiß ich... etwas offentsichtliches wäre, dass die dummen nicht mit Vorbehalt schießen.

    Die Fieguren der verschiedenen Schwierigkeitsstufen werden per Objekt-Factory erstellt. Du musst dich also nicht darum kümmern.

    Und jetzt merkst du Irgendwie ist der unterschied zweischen den beiden Stufen viel zu groß. Also willst du eine dritte stufe einführen. Kein Problem. Klassen schreiben Factory minimal anpassen. Fertig.

    Jetzt mach das bitte mal Prozedural. Da darfst du jede Prozedur, die irgendwie mit Gegnern in Kontakt kommt überarbeiten, wogegen in der OO-Version nicht, aber absolut gar nichts geändert werden muss.

    0
  • S

    naja dafor musst du deine klassen ja erstellen wenn ich meine structs nehme und ein paar intelligente funktionen dazu muss ich auch nichts ändern 😉
    auf jeden fall habe ich meine structs sicher schneller erstellt und kann dann besser mit dem inhalt spielen als du mit deinen klassen

    0
  • H

    naja dafor musst du deine klassen ja erstellen wenn ich meine structs nehme und ein paar intelligente funktionen dazu muss ich auch nichts ändern
    auf jeden fall habe ich meine structs sicher schneller erstellt und kann dann besser mit dem inhalt spielen als du mit deinen klassen

    Nein.

    void ziele_auf_spieler (Monkeys_gegner & gegner)
{
   if (level == easy) {
      if (gegner.kind == goblin) {
         // dumme Version
      }
      else if (gegner.kind == oger) {
         // dumme Version
      }
   }
   else if (level == hardcore) {
      if (gegner.kind == goblin) {
         // super intelligente Version
      }
      else if (gegner.kind == oger) {
         // super intelligente Version
      }
}

... irgendwo ()
{
   ziele_auf_spieler (ein_gegner)
}

    'ziele_auf_spieler' Muss auf jeden Fall erweitert werden.

    In der OO-Vsion kommt zwar genau die selbe Menge Code dazu, jedoch muss
    nicht an vorhandenem Code gebastelt werden. Versehentliche änderungen sind also ausgechlossen. Und sowas, wie durch Copy&Paste ein

    void ziele_auf_spieler (Monkeys_gegner & gegner)
{
   if (level == easy) {
      if (gegner.kind == goblin) {
         // dumme Version
      }
      else if (gegner.kind == oger) {
         // dumme Version
      }
   }
   else if (level == hardcore) {
      if (gegner.kind == goblin) {
         // halbwegs intelligente Version
      }
      else if (gegner.kind == oger) {
         // halbwegs intelligente Version
      }
   else if (level == hardcore) {
      if (gegner.kind == goblin) {
         // super intelligente Version
      }
      else if (gegner.kind == oger) {
         // super intelligente Version

   }
}

    kann dir auch nicht passieren. Und der Code ist wesentlich übersichtlicher. Selbst, wenn du noch 20 weitere Schwierigkeitstufen einfügst wird der OO-Code kein stück unübersichtlicher (bis auf vielleicht die Factory), wogegen quasi jede Prozedur, die was mit Gegner zu tun hat zu einem gigantischen, nicht mehr handhabbaren Monster herranwächst.

    Es wird einfach

    gegner.ziele_auf_spieler();

    Aufgerufen. Egal, wieviele Schwierigkeitstufen oder Monsterarten es gibt. Es wird automatisch (dank Polymorphie) die richtige Methode aufgerufen.

    Und dann ist da noch die Wiederverwendbarkeit.

    Und wenn du es mal vernüpftig ausrobiert wirst du feststellen, das da noch viel mehr ist.

    0
  • T

    Hoi.

    Also ich hab früher auch viel mehr ohne OOP geproggt, da mir das mit den Klassen etwas fremdes war.
    Und als allererstes sagt man ja immer das Klassen gut sind, wenn man viele Instanzen davon erstellt.
    Das muß aber garnicht sein.

    Ich finde es einfach etwas lesbarer, weil ich hier viel eher sehen kann welche Daten zu welchen Methoden gehören.

    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.

    Ich denke man muß sich einfach mal etwas näher mit OOP außerinandersetzen.
    Klar ist es nicht das Allheilmittel, aber wenn man seinen Programmierstil etwas abändert um somit auch mehr von Vererbung, virtuellen Methoden und der gleichen Gebrauch macht, kommt man bei dem ein oder anderem Programm wohl auch auf den Geschmack von OOP.

    0
  • S

    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 🤡

    0
  • ?

    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!

    0
  • H

    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.

    0
  • S

    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...

    0
  • S

    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...

    0
  • S

    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...

    0
  • S

    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.

    0
  • S

    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 😃

    0
  • S

    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.

    0
  • S

    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.

    0
  • S

    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)

    0
  • S

    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?

    0
  • O

    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

    0
Anmelden zum Antworten