PureBoard

Es gibt genug Programmierer (darunter auch Alexander Stepanov)die OOP für großen Mist und eine Lüge halten:

1. OOP steigert die Produktivität NICHT gegenüber procedural. (http://doc.cat-v.org/programming/bad_properties_of_OO)
2. OOP mischt Daten und Codesegmente. Absolut unsauber.
3. OOP ist wesentlich langsamer als procedurale Programmierung.
4. Ich könnte endlos so weitermachen ....

OOP bremst.
OOP erzeugt oft gegenüber prozeduraler Programmierung mehr Output-Code.

Das ist vollkommen klar.
Es behauptet auch keiner, dass da die Stärken der OOP liegen.

Die Stärken der OOP liegen vor allem in der Kabselbarkeit von funktionalen Aspekten inklusive ihrer Daten.
Dadurch haben Klassen einen imensen Wiederverwendbarkeitswert.
Nicht nur Projektübergreifend, sondern auch exklusiv im Projekt durch Vererbung.

Ich muss mir bei einer Klasse kaum Gedanken machen ob sie auch später noch in andere Projekte passt.
Denn z.B. Namenskollsionen sind durch die Kapselung nahezu ausgeschlossen.
Das gilt für die Schnittstelle sowie für die Daten der Klasse.

Der Sinn der OOP ist es sicherlich nicht, ein paar Klassen lose als Backends in einer Applikation unterzubringen.
Da ist klar, macht OOP keinen Sinn.
Denn dann könnte ich auch modular Programmieren.

Richtig Sinn macht es, wenn ich in der OOP die verschiedenen Teil-Aspekte auf ein Minimum separiere um sie Projektweit mehrfach einsetzen zu können.

Dadurch kann man kleinste Grundfähigkeiten vordefinieren um sie Klassen höherer Aspekte zu vererben.

Sicher hat die OOP keinen Sinn in der 64k Intro-Programmierung.
Dazu ists auch nicht da.
Man muss generell abwegen welche Techniken man für bestimmte Probleme einsetzt.

Aber generell OOP als eine grosse Lüge hinzustellen ist schon etwas Lustig und kann nicht ernst genommen werden.
Vor allem dann wenn es so bedingungslos hingestellt wird.

MfG

Wolf

Ich hab nicht allgemein OOP als Lüge hingestellt sondern nur Zitiert und auf den nicht vorhandenen Produktivitätsunterschied hingewiesen.

Sicher, OOP hat durchaus Sinn, so wie du es beschrieben hast. Mit proceduraler Programmierung kann man das ganze aber auch lösen.

Ist mir persönlich viel lieber.

PB ist halt eine prozedurale Programmiersprache. Ich denke nicht das sich da mal ändern wird. Die Entscheidung wurde sicherlich schon getroffen als PB noch nur eine Überlegung war. OOP und Prozedural sind halt 2 Modelle. Beide haben Vorteile und Nachteile. Ich persönlich bevorzuge Prozedural aus einigen Gründen.

Ich weis noch wie ich mich gefreut habe von VB (OOP) wieder zurück zur prozeduralen Programmierung zu kommen mit PB. Der einzige Vorteil den VB gegenüber PB hat, ist der visualle Designer, der ist sowas von genial. Aber sonst... nix.

cxAlex hat geschrieben:1. OOP steigert die Produktivität NICHT gegenüber procedural. (http://doc.cat-v.org/programming/bad_properties_of_OO)
2. OOP mischt Daten und Codesegmente. Absolut unsauber.
3. OOP ist wesentlich langsamer als procedurale Programmierung.
4. Ich könnte endlos so weitermachen ....

Stimmt so ziemlich alles nicht.

1. OOP steigert die Produktivität - Das ist bewiesen. Durchschnittlich mehr als 50% der Arbeit liegt heutzutage in der Wartung der Software. Und ein OOP Projekt nach 3 Jahren wieder zu lesen wenn mal die Dokumentation schlecht war, ist wesentlich einfacher als ein prozedurales Projekt. Unser Gehirn denkt auch in OOP, immerhin sehen wir "Bäume" außer wir sind Förster oder irgendwelche Holzarbeiter, dann sehen wir "Bäume" unterteilt in "Fichte", "Tanne", "Buche", ... .
2. Wo mischt OOP Daten und Codesegmente? Ich habe das nur in PureBasic einmal gesehen in einem späten Beispiel und das fand ich unsauber.
3. Das stimmt so auch nicht. Klar, ein weiterer Parameter in jeder Methode, aber es gibt Methoden die kommen auch ohne diesen Parameter aus (Klassenmethode) und wenn man dann noch diese modernen JIT Compiler anguckt gibts kaum was schnelleres.
4. Das stimmt auch nicht, irgendwann ist Schluss.

Ich steh auf OOP, aber ich nutze immernoch PB für Kleinigkeiten (wie nen Fließkommazahlumrechner oder eine Online-Rechnungsschreibwollmilchsau für meinen Onkel)

DarkDragon hat geschrieben: 1. OOP steigert die Produktivität - Das ist bewiesen. Durchschnittlich mehr als 50% der Arbeit liegt heutzutage in der Wartung der Software. Und ein OOP Projekt nach 3 Jahren wieder zu lesen wenn mal die Dokumentation schlecht war, ist wesentlich einfacher als ein prozedurales Projekt. Unser Gehirn denkt auch in OOP, immerhin sehen wir "Bäume" außer wir sind Förster oder irgendwelche Holzarbeiter, dann sehen wir "Bäume" unterteilt in "Fichte", "Tanne", "Buche", ... .

Da hab gegenteilige Erfahrungen gemacht. Die Abstraktion von OOP erschwert Bugfixing/Debugging teilweise erheblich. Ich hatte in VB so viele echt strange Effekte wo ich einfach nicht durchgeblickt hab. Ganz einfach weil ich keine Ahnung hab was da unter der Haube alles abgeht.

Wer drauf steht bitte. Aber den Beweis für die Produktivität will ich sehen.

Thorium hat geschrieben:Aber den Beweis für die Produktivität will ich sehen.

wie soll man das denn beweisen? Ich habe mehr Programme mit OOP zur
Release-Reife gebracht als ohne OOP. Aber was beweist das schon?

Grüße ... Kiffi

Kiffi hat geschrieben:

Thorium hat geschrieben:Aber den Beweis für die Produktivität will ich sehen.

wie soll man das denn beweisen?

Ich hab keine Ahnung wie man das beweisen soll. Aber Wenn DD schreibt das es erwiesen ist dann muss es auch beweisbar sein, ansonsten wäre es ja nicht erwiesen.

Na, mal wieder ne Diskussion über Objekt orientiert oder nicht

Man braucht doch nicht wissen, was "ab geht".

Weiß man das bei einer Prozedur immer so genau?

Ich bin zurzeit dabei mit einem "Kollegen" eine Idee für eine neuartige
Form der Programmierung umzusetzen, die prozedural bleibt, aber
eigentlich objektorientiert ist.

JAVA zum Beispiel kann man auch komplett prozedural nutzen. Das hat
nicht allein was mit der Sprache zu tun, sondern auch mit der Benutzung.

Fakt ist aber, dass es oft Objekte gibt, auf die man zugreifen möchte bzw.
muss. Im Leben und in der Programmierung.

Und es ist oft einfacher, wenn man sich die menschliche Sprache anschaut,
auch die Programmiersprache so zu wählen.

Ohne dir jetzt ganz wiedersprechen zu wollen DD,
bin ich doch mit deiner ersten Aussage nicht einverstanden.
(Gegen OOP will ich nicht sagen, weil ich nicht kenne.
Der einzige Nachteil den auch ich deutlich sehe: längere Codes)

DarkDragon hat geschrieben: 1. OOP steigert die Produktivität - Das ist bewiesen. Durchschnittlich mehr als 50% der Arbeit liegt heutzutage in der Wartung der Software. Und ein OOP Projekt nach 3 Jahren wieder zu lesen wenn mal die Dokumentation schlecht war, ist wesentlich einfacher als ein prozedurales Projekt. Unser Gehirn denkt auch in OOP, immerhin sehen wir "Bäume" außer wir sind Förster oder irgendwelche Holzarbeiter, dann sehen wir "Bäume" unterteilt in "Fichte", "Tanne", "Buche", ... .

In meine Prozeduralen Codes finde ich mich nach 3 Minuten wieder ein, wenn sie groß sind.
Was ich dafür brauche, ist ein für mich brauchbarer Programmierstil, und ein Kommentar ca alle 40 Zeilen.
Jemand anderen hab ich erst einmal einen großen Code gegeben.
Der konnte nach 10 Minuten und Erklärungen meinerseits
damit weiterarbeiten.

Ich denke übrigens in vielen Dingen prozedural.
(Multithreaded ^^)
Ich mache etwas, um zu einem Ergebnis zu kommen, mit dem ich dann weiterarbeite.
Und ein Baum ist eben nicht Baum für mich.
Baum ist entweder "Einzige große Kastanie im Ort"-->Schaun ob schon welche oben hängen/alle heruntergefallen sind oder
"Ignoriert"

Die Diskussion ist doch eh fürn Arsch. Jeder soll das benutzen was ihm am meisten liegt bzw. was für die jeweilige Aufgabe geeignet ist.