OO ist gescheitert

Diskutiere OO ist gescheitert im Softwareentwicklung Bereich.

Ist OO (definiert nach Alan Key) gescheitert?

  • JA

  • NEIN


Die Ergebnisse sind erst nach der Abstimmung einsehbar.
mrBrown

mrBrown

Ich habe eine Funktionalität, die ich realisieren möchte.
Ich habe erstmal eine Problemstellung, die ich lösen möchte.
Das *wie* (die Funktionalität) gibt die erstmal nicht vor.
Aus der Modellierung des Problems ergibt sich dann die Umsetzung. Die kann OOP sein, die kann PP sein, die kann FP sein. Wenn man aber Funktionalität beliebig von einer Umsetzung in die anderen umformen kann, kommt Bullshit raus - eben weil der wesentliche Schritt, die Modellierung, fehlt.

Ich setz dich auch nicht vor Schloss Neuschwanstein und lass dich das zu einem Hochhaus umbauen.

Von daher müsste beides ineinander umformbar sein. Falls nicht, zeigt es doch eindeutig, dass OO stark einschränkend ist, oder aber eine verkomplizierte und nicht ressourcenschonende Programmierung vorraussetzt.
Alle Sprachen sind ineinander umformbar.
Du kannst das auch mit Powerpoint umsetzen, zeigt das jetzt, dass PP nicht besser ist als Powerpoint?

siehe BSP diese ActionObjects, zumal ich von denen sowieso behaupten würde, dass diese Prozedural sind, nur eben mit ein paar Keywörtern aus der Objektorientierung
Wenn du die Kombination aus Verhalten und Daten als Prozedural siehst, kannst du das gern machen. Wenn du aber zwischen OOP und PP keinen Unterschied siehst, ist diese Diskussion hier ziemlicher Unsinn...


Nein es muss nicht alles alles kennen. Aber zumindest Modulintern wäre das ziemlich schön.
Gehen wir davon aus unser Sonnensystem ist nur ein kleines Modul ist, in einem System das viel Größer ist.
Und in dem größerem System haben wir zwei vollkommen unabhängige Sonnensysteme. Die trotzdem vollen Zugriff aufeinander haben sollen?

Modul != Klasse (zumindest sollte es so sein?!)

Und das ist das Problem: Jede klasse ist in sich genommen ein eigenes abgeschottetes Modul.
Also Klassen sind keine Module aber Klassen sind Module? Du solltest dich schon für eine Sichtweise entscheiden, auch wenn beide Begründbar sind...

Analog.
Modul != Prozedur
Und das ist das Problem: Jede Prozedur ist in sich genommen ein eigenes abgeschottetes Modul.

Also ist OO überall da falsch, wo ich Dinge/Funktionalität auf mindestens zwei Klassen aufteilen muss?
Diese aber voneinander wissen müssen, damit das Gesamtkonzept funktioniert?
Also sprich ist OO immer falsch?!^^
Nein, OO ist falsch, wenn es *keinerlei* Kapselung geben soll und dir alles völlig egal ist.
(Und OO ist falsch, wenn man es nicht verstanden hat, für dich also immer ;) )

Etwas mehr Kreativität. Die Welt so wie sie ist, ist doch langweilig, in meiner erfundenen Welt ginge das beispielsweise^^
Klar wenn ich jetzt irgendwas aus der uns bekannten Welt abbilden möchte, da ginge das nicht. Aber sobald du eben ein Computerspiel oder Sonstiges entwirfst, da sollten dir keine Grenzen gesetzt sein und schon gar nicht von einem Programmierparadigma. Die Gesetzmäßigkeiten in dem Programm gibst du selbst vor und sollten dir nicht von dem Programmierparadigma vorgegeben werden.
Wenn das möglich ist, modellierst du das auch so, da steht dir OO überhaupt nicht im Wege...
Welche Computerspiele sind eigentlich noch rein Prozedural umgesetzt? ;)

Und das ist noch ein weiterer schlechter Beigeschmack seitens OO. Warum sollte ich 42 verschiedenartige Implementierungen machen wollen?
Weil es 42 verschiedene Implementierungsmöglichkeiten gibt? Hint: 42 steht da nur wegen 42.
Was übrigens auch Typen sind: Object, Compareable, Serializable, Cloneable, etc. Für die solltest du die 42 um ein paar Nullen ergänzen.

ABER das ist auch der einzige vorteil, wenn da class BankRepo steht statt nen einfachen Call wie give_me_Bank(id, sonstiges);

btw. wäre auch das noch möglich give_me_bank(id, implementierungs_ID, sonstiges); ^^
Was gibt denn give_me_bank eigentlich zurück?
Vielleicht ein Bank-Objekt?

das ganze ressourcenfressender/langsamer ist
NEIN! immer noch nicht. Das sage ich jetzt gefühlt in jedem Beitrag. Egal wie oft du es wiederholst, es wird nicht richtiger.

mir keine weiteren Vorteile einräumt.
Warum sollte ich dann Zweiteres verwenden?
Warum sollte ich allgemein irgendwas davon verwenden, wenn ich OO programmieren möchte?
Wie gesagt es sind beide Realisierungen prozedural.
Wer sagt, dass man das Objekt an der Stelle verwenden muss? Ist üblich, sowas im Programm rumzureichen.

Und wie gesagt, die eine Implementierung ist OO.

Könntest du DI etwas weiter ausführen, wie du es einsetzt. vllt. auch ein/zwei/gar 3? gute Codebeispiel(e)^^, was/welche mich somit dann schon eher von OO überzeugen könnte^^
Guck dir ein beliebiges Buch an, was sich mit OO beschäftigt. Können die besser erklären als ich (wird dich aber trotzdem nicht überzeugen^^)
Es ist auch ganz einfach: Immer, wenn du einem Objekt etwas übergibst, was es benötigt, ist es DI.
Jeder Konstruktor mit nicht primitiven Parametern ist DI.

Hier muss man einfach die Kreativität wieder einschalten, dann geht das schon^^
Wie gesagt: du kannst für alles irgendwas erfinden, was deinen Punkt stützt ;)
Ich möchte aber er selten, dass in meinem Haus Dachboden und Keller verwoben werden. Wäre doof, weil ich dazwischen wohne.

Wie soll ich mein Motoorradmotor mit der Sonneninnentemperatur verknüpfen, wenn beides in gleichem Modul liegt und ich das ganze OO gestalten möchte?
Unabhängig von Module: Dependency-Injection. (mit dem Zusatz, dass so ein Design trotzdem Bullshit ist)

also ich finde schon, dass man entweder 100%iges OO programmieren sollte, oder gar nicht.
Zumindest aber müsste es ja möglich sein 100%iges OO einschränkungslos programmieren zu können?, wenn es das Paradigma der heutigen Wahl ist?!^^
das findest *du*, aber zum Glück auch nur du ;)


Jetzt habe ich mal wieder ein praktisches Beispiel:
Dazu schreib ich gleich was
 
Zuletzt bearbeitet:
X

Xyz1

sind beides prozedurale Realisierungen. Nur das zweiteres eben Keywörter aus der objektorientierung verwendet, das ganze ressourcenfressender/langsamer ist und mir keine weiteren Vorteile einräumt.
Warum sollte ich dann Zweiteres verwenden?
Warum sollte ich allgemein irgendwas davon verwenden, wenn ich OO programmieren möchte?
Alles richtig!!!, zudem und, um das zu verkomplettieren.... bitte bedenken dass Java bei übermäßigem PP-Einsatz sehr langsam wird....

Prinzipiell lässt sich dein ganzer Beitrag auf nur dieses Zitat verkleinern....

Also.... schön erklärt - ich werde auch weiterhin lesen was du schreibst. :)
 
M

Meniskusschaden

Und OO ist falsch, wenn man es nicht verstanden hat
Vermutlich kann man deshalb ein vermurkstes PP-Projekt länger am Leben halten bis es zum Kollaps kommt, als ein vermurkstes OO-Projekt. Wenn man möchte, kann man darin vielleicht einen Vorteil für die PP-Programmierung sehen. Ich finde es aber besser, wenn man möglichst früh erkennt, dass man Mist baut. Aus meiner Sicht also doch ein pro OO Argument.;) Allerdings sehe ich es tatsächlich als Vorteil der PP, dass man dafür mit einer geringeren Qualifikation auskommt. Das wiegt aber die Nachteile nicht auf.
 
mrBrown

mrBrown

Jetzt habe ich mal wieder ein praktisches Beispiel:


Gehen wir mal davon aus ich baue einen Chat, ...
Den Teil hab ich mal hier ausgelagert, ist ja generell ein ganz interessantes Thema und unabhängig hiervon:
https://www.java-forum.org/thema/mo...r-von-oo-ist-gescheitert.182236/#post-1159377



Nein tatsächlich nicht, bin Informatik Student^^
An der Uni lernt man aber kein gutes Coding.
Das hängt sehr stark von der Uni und dem Studiengang ab ;)
Die Diskussion hier befindet sich aber nicht mal auf Coding-Ebene, sondern darüber. Und zumindest Modellierung sollte man auch in der Uni schon zumindest in Ansätzen lernen...
Aber ja (und da spreche ich für beide Seiten der Veranstaltungen), ich finde auch, dass der "Software Engineering"-Teil deutlich zu kurz kommt, betrifft an Unis leider nicht nur die Studierenden...


Rein aus Interesse, was studierst du? Nur "Informatik" oder irgendwas spezielleres?

Also wenn du nichts dagegen hast, könnten wir auch mal skypen/discorden/teamspeaken etc pp.
Eigentlich finde ich das hier angenehme - solche Diskussionen nur zu zweit finde ich immer etwas schade ;)
 
X

Xyz1

Vermutlich kann man deshalb ein vermurkstes PP-Projekt länger am Leben halten bis es zum Kollaps kommt,
Soll das ne Anspielung mit PP-Projekt auf mich sein, weil ich mich zumindest nicht (wie die anderen Teilnehmer der Diskussion) gegen PP-Projekte geäußert habe????
Allerdings sehe ich es tatsächlich als Vorteil der PP, dass man dafür mit einer geringeren Qualifikation auskommt.
Sehr blauäugig, bei Nicht-OO-Projekten von einer geringeren Qualifikation zu sprechen....
 
mrBrown

mrBrown

Soll das ne Anspielung mit PP-Projekt auf mich sein, weil ich mich zumindest nicht (wie die anderen Teilnehmer der Diskussion) gegen PP-Projekte geäußert habe????
Ja, alles was in irgendeiner Art und Weise als Kritik verstanden werden könnte, meint immer, ohne Ausnahme, dich.

Sehr blauäugig, bei Nicht-OO-Projekten von einer geringeren Qualifikation zu sprechen....
Hat er nicht.
 
K

knotenpunkt

Hey,

Ich habe erstmal eine Problemstellung, die ich lösen möchte.
Das *wie* (die Funktionalität) gibt die erstmal nicht vor.
Aus der Modellierung des Problems ergibt sich dann die Umsetzung. Die kann OOP sein, die kann PP sein, die kann FP sein. Wenn man aber Funktionalität beliebig von einer Umsetzung in die anderen umformen kann, kommt Bullshit raus - eben weil der wesentliche Schritt, die Modellierung, fehlt.

Ich setz dich auch nicht vor Schloss Neuschwanstein und lass dich das zu einem Hochhaus umbauen.
Ja aber von der Umsetzung aus, müsste ich ja wieder zurück zur Problemstellung kommen.
Somit kann ich die Problemstellung neu modellieren und so eine nicht bullshitkonforme Umwandlung von PP zu OO erreichen?^^


Wenn du die Kombination aus Verhalten und Daten als Prozedural siehst, kannst du das gern machen. Wenn du aber zwischen OOP und PP keinen Unterschied siehst, ist diese Diskussion hier ziemlicher Unsinn...
ActionObjects, eine Art Kombination aus Verhalten und Daten sehe ich definitiv als Prozedural an.
Du siehst das offensichtlich als OO an?

Da ActionObjects nichts anderes wie ein procedure-call sind, sind für dich diese auch OO?
wenn ich eine Prozedur aufrufe, dann kombiniere ich - zwar für kurzen Zeitraum - auch Daten und Verhalten.
Das Tolle an der Kombination ist, dass ich meist 100%ig das Single-Responsibility-Prinzip einhalte. Außerdem habe ich keine weiteren unnötigen Abhängigkeiten.
Alle Daten, die ich der Prozedur übergebe werden auch benötigt, um exakt diese Funktionalität auszuführen.

function x(this[a,b,c,d], sonstiges1)
function y(this[c,k,u,z], sonstiges2)

Die Prozeduren x und y sollen eine C-ähnliche Umsetzung (aus der Syntax Sicht) der Objektorientierung zeigen.

x benötigt die die daten a b c und d
y benötigt k u z und das gleiche Datum c, was auch von x benötigt wird.

Um x ausführen zu können, muss ich x aber auch unnötigerweise k, u und z zur Verfügung stellen
=> unnötige Datensturkopplung
Ausnahme: Das ganze würde ich dann in Kauf nehmen, wenn x und y nur Datenänderungen auf this ausführen, aber keine Seiteneffekte hat!
Von daher macht OO schon sinn, aber eben nur bei ADTS (abstrakte Datentypen), und damit meine ich bspw. irgendwelche Listen, Queues, Stacks etc pp.

Das ist noch ein anderer Aspekt, warum ich OO im Allgemeinen nicht als sehr sinnvoll erachte.

Anyway: ich gehe davon aus, dass du einen Prozeudurenaufruf nicht als OO ansiehst, auch wenn es das gleiche wie diese ActionObjects ist?!
Wie würdest du hier dann selbst zwischen OO und PP differenzieren?



Und in dem größerem System haben wir zwei vollkommen unabhängige Sonnensysteme. Die trotzdem vollen Zugriff aufeinander haben sollen?
Module sind schon sinnvoll. Aber OO macht den Eindruck, dass jedes Byte (Klasse) ein eigenes Modul darstellt.
Ok zwei vollkommen unabhängige Sonnensysteme haben keinen vollen Zugriff aufeinander. Wie würdest du nun in dem Modul Sonnsnesystem-Erde mit der Problemstellung Motorradmotor und Sonneninentemperatur sinnvoll in der OO umsetzen?

Also Klassen sind keine Module aber Klassen sind Module? Du solltest dich schon für eine Sichtweise entscheiden, auch wenn beide Begründbar sind...

Analog.
Modul != Prozedur
Und das ist das Problem: Jede Prozedur ist in sich genommen ein eigenes abgeschottetes Modul.
Das habe ich absichtlich so paradox stehen geschrieben^^

Meine Sichtweise ist die, dass es Unsinn ist, dass das was Klassen repräsentieren jeweils eigene Module sind.

Da ich jetzt aber eine Klasse Motorradmotor und eine Klasse Sonne habe, wie auch viele anderen Klassen noch dazwischen, macht das den Eindruck, weil es dir so schwer fällt diese zwei Dinge zusammenzubekommen, dass jede Klasse einem eigenen Modul entspricht.

Und das ist ja auch irgendwie so?!
Oder nicht?!

Die Frage gebe ich also an dich zurück, ist eine Klasse == Modul ODER ist Klasse !=Modul ?

Zu deiner Aussage, dass Modul==Prozedur:
Das ist doch super, so kann ich jede prozedur für sich genommen testen^^
Ausserdem kann ich die Prozeduren von überall aus aufrufen, ohne mich vorher durch langsame Graphenstrukturen hangeln zu müssen. (Zumal das ja eh nicht gewollt ist?, Siehe ein Beispiel nahe am Anfang dieses Threads hier und deine Aussage dazu^^)

Wenn ich jetzt Klassen verwende, dann verstecke ich Funktionalität hinter diesen. Bei verschachtelten Klassen komme ich von aussen erst gar nicht an innerere Klasse heran. Es sei denn ich baue riessige facadenhafte Delegationsstrukturen (das ist doch dann unübersichtlicher Code^^), oder ich baue ne get-chain (das selbe in blau^^), um an innere Klassen/Objekte zu kommen

Von daher jetzt auch mein Chat-Server-Beispiel.
Hier würde ich gerne mal von euch sehen, wo ihr die Funktionalität hinklatscht und wie auf diese zugegriffen werden kann^^



Nein, OO ist falsch, wenn es *keinerlei* Kapselung geben soll und dir alles völlig egal ist.
(Und OO ist falsch, wenn man es nicht verstanden hat, für dich also immer ;) )
Dann erklär doch mal auf ein Verständnis meinerseits zielend, die Objektorientierung^^



Was gibt denn give_me_bank eigentlich zurück?
Vielleicht ein Bank-Objekt?
Ein Bank-Objekt, ein Bank-Struct or whatever^^
give_me_bank(id,values[x,y,z])
das hier gibt bspw. nen bank-struct nur mit den Werten x y und z zurück

give_me_bank_info(id), das hier gibt mir nen Info text zur Bank mit der ID id zurück

transfer_money(bank_id1, bank_2, ktrn1, ktnr2, value, currency, automaticCurrencyTransformation);
Hier brauche ich keine Bankobjekte. Ausserdem interessiert es mich auch nicht wie das ganze gemacht wird.
Eventuell erledigt transfer_money das ganze sogar nur durch ein paar Datenbank-Queries
Auch um irgendwelche ACID-Regeln muss ich mir keine Gedanken machen
Das ist doch ne tolle Programmiert Art so^^

Ja klassische prozedurale Programmierung eben^^


Wer sagt, dass man das Objekt an der Stelle verwenden muss? Ist üblich, sowas im Programm rumzureichen.

Und wie gesagt, die eine Implementierung ist OO.
Da kann ich aber auch ein Struct herumreichen^^
Die Implementierung verwendet Keywords aus der OO, aber ist das wirklich OO?


Guck dir ein beliebiges Buch an, was sich mit OO beschäftigt. Können die besser erklären als ich (wird dich aber trotzdem nicht überzeugen^^)
Es ist auch ganz einfach: Immer, wenn du einem Objekt etwas übergibst, was es benötigt, ist es DI.
Jeder Konstruktor mit nicht primitiven Parametern ist DI.
Ja wenn DI das Non plus Ultra ist, dann passt doch dazu die prozeudurale Programmierung perfekt^^
Weil hier injecte ich wirklich IMMER und OHNE AUSNAHME^^ zur Laufzeit Daten in die Prozedur.

Sobald ich feste Strukuren verwende, fest angelegte Objektwelten, bin ich eingeschränkter, unflexibler (wenn ich mir die Flexibilität zurückholen möchte, bin ich unperfomanter).

Vielen anderen scheint das auch zu starr zu sein, von daher DI?
Warum aber nicht das höchste der Gefühle, das Flexibelste was es gibt? Eine Prozdur, in die ich wirklich jedes mal injecte?!!!!^^

DI, Services, ActionObjekts sind eindeutige Indizien dafür, dass sich die Leute gegen OO wehren!
Der Kampf gegen OO hat also schon begonnen.
Ich hoffe er wird auch zu Gunsten der prozeduralen Programmierung gewonnen^^

DI, Services, ActionsObjekts sind auch ein Zeichen dafür, dass sich Programmierer noch nicht ganz eingestehen möchten, dass OO einfach nicht gut ist und somit mit guter Miene zum bösen Spiel ein Art pseudo OO programmieren, das hoffenltich irgendwann wieder mehr ins reine prozedurale übergeht, was die Keywords betrifft, da es einfach perfomanter ist^^

Unabhängig von Module: Dependency-Injection. (mit dem Zusatz, dass so ein Design trotzdem Bullshit ist)
Mach doch mal ein konkretes Beispiel, wie derartiges aussehen könnte.
Folgender Anwendungsfall:
Motorrad soll explodieren, wenn er 7k Umdrehungen hat und die Sonneninnentemparatur sich zwischen temp x und temp y aufhält^^



das findest *du*, aber zum Glück auch nur du ;)
Also du sagst damit, dass du selbst auch prozedural programmierst?
In welchen Bereichen deiner Software, wird diese objektorientiert sein (und warum?), in welchen prozedural (und warum?)

Dazu schreib ich gleich was
Darauf werde ich dort dann später noch antworten^^

Rein aus Interesse, was studierst du? Nur "Informatik" oder irgendwas spezielleres?
Nur Informatik^^

Eigentlich finde ich das hier angenehme - solche Diskussionen nur zu zweit finde ich immer etwas schade ;)
Das eine schließt das andere ja nicht aus^^

ok soweit in diesem Thread hier mal wieder


lg knotenpunkt
 
mihe7

mihe7

userRight=......//lese aus der DB herauz welche Rechte der User hat
//.....

if(/*hier wird alles mögliche geprüft*/)
Das "hier wird alles mögliche geprüft" zeigt genau das Problem: Du bist hier nicht flexibel, sondern genau das Gegenteil ist der Fall. Machen wir das einmal konkreter:

Code:
if (canPost(userRight, room, command)) {
...
}
Die Logik ist fest im Code verankert. Diese Stelle im Programm ist abhängig von den Implementierungsdetails. Zur Übersetzungszeit steht genau fest, was wann passieren muss. Das Regelsystem ist starr. Soll daran etwas geändert werden, muss der Code geändert werden und dieses Modul neu übersetzt werden.

Und das lässt sich in OO sehr einfach umgehen:
Code:
interface PostPolicy {
    boolean canPost(...);
}
Der Code oben ändert sich damit zu:
Code:
if (policy.canPost(...)) {
}
Die Policy könnte z. B. per DI injected werden:
Code:
private PostPolicy policy;
public void setPolicy(PostPolicy p) { policy = p; }
Die betreffende Klasse arbeitet jetzt völlig unabhängig von Implementierungsdetails. Willst Du eine einfache Policy? Kein Problem, setze sie. Willst Du eine komplexe Policy? Ebenfalls kein Problem, setze sie.
 
mrBrown

mrBrown

Ja aber von der Umsetzung aus, müsste ich ja wieder zurück zur Problemstellung kommen.
Somit kann ich die Problemstellung neu modellieren und so eine nicht bullshitkonforme Umwandlung von PP zu OO erreichen?^^
Äh, nein?

Wie kommt man denn von sowas:
Code:
{
data x;
data y;
data z;

switch(variable k)
case 1;//x und y werden verändert
case 2;//y und z werden verändert
usw
}
zu der dahinter stehenden Problemstellung?
Wenn du aus 3 beliebig benannten Variablen die Problemstellung erkennst, wundert es mich, dass du hier schreibst und nicht grad irgendwo mit einem vierstelligen Stundensatz arbeitest...

ActionObjects, eine Art Kombination aus Verhalten und Daten sehe ich definitiv als Prozedural an.
Du siehst das offensichtlich als OO an?
Ein Objekt welches einen gekapselten Zustand hat, und dem man Nachrichten schicken kann - ja, das sehe ich schon irgendwie als OO an (guck einfach noch mal auf deine Definition im Ursprungspost...).


Das nachfolgende ist dementsprechend Unsinn. Ein Prozeduraufruf macht aus eine Prozedur noch lange nichts OO-artiges, das ist völliger Unsinn jeglicher Definition nach.

Ok zwei vollkommen unabhängige Sonnensysteme haben keinen vollen Zugriff aufeinander. Wie würdest du nun in dem Modul Sonnsnesystem-Erde mit der Problemstellung Motorradmotor und Sonneninentemperatur sinnvoll in der OO umsetzen?
Und damit darfst du keinen globalen Zustand mehr haben (auch wenn global in diesem Fall auf ein Modul eingeschränkt ist, sondern musst es alles durchreichen.
Und das wäre auch die OO-Lösung: Dependency Injection (im einfachsten Fall mit Durchreichen).

Meine Sichtweise ist die, dass es Unsinn ist, dass das was Klassen repräsentieren jeweils eigene Module sind.
Aber Prozeduren (und damit auch Structs?) siehst du als einzelne Module an?

Da ich jetzt aber eine Klasse Motorradmotor und eine Klasse Sonne habe, wie auch viele anderen Klassen noch dazwischen, macht das den Eindruck, weil es dir so schwer fällt diese zwei Dinge zusammenzubekommen, dass jede Klasse einem eigenen Modul entspricht.
Wie bekommst du denn den Struct Motorradmotor und den Struct Sonne zusammen, die beide einzelnen Modulen entsprechen sollen?
Das was du beschreibst, ist kein OO-Problem.


Da kann ich aber auch ein Struct herumreichen^^
Die Implementierung verwendet Keywords aus der OO, aber ist das wirklich OO?
Du kannst ein Struct rumreichen, klar, aber mit Objekten hast du eben die zu den Daten gehörenden Funktionen, darum geht es doch ^^
Ja wenn DI das Non plus Ultra ist, dann passt doch dazu die prozeudurale Programmierung perfekt^^
Weil hier injecte ich wirklich IMMER und OHNE AUSNAHME^^ zur Laufzeit Daten in die Prozedur.
DATEN, bei OO injectest du Daten UND FUNKTIONEN auf diesen. Genau darum geht es doch.

DI, Services, ActionObjekts sind eindeutige Indizien dafür, dass sich die Leute gegen OO wehren!
Der Kampf gegen OO hat also schon begonnen.
Ich hoffe er wird auch zu Gunsten der prozeduralen Programmierung gewonnen^^
Eigentlich sind das alles Indizien, dass sie OO nutzen.
DI, Services, ActionObjekts SIND KEINE PP, es sind immer DATEN UND FUNKTIONEN - und mit einem ohne das andere kann man an der Stelle nichts anfangen.

Motorrad soll explodieren, wenn er 7k Umdrehungen hat und die Sonneninnentemparatur sich zwischen temp x und temp y aufhält^^
Code:
UnsinnigeExplosion : ExplosionsStrategie {
@Inject Motoradmotor motor
@Inject Sonne sonne

shouldExplode =>
motor.umdregungen > 7000 && sonne.innenTemp>y && sonne.innenTemp<y

}

Motorad {
@Inject ExplosionsStrategie explosionsStrategie

...
if explosionsStrategie.shouldExplode: explode()
...

}

Wie sieht denn die PP-Variante aus? (Und denk dabei an das von oben, Sonnensystem ist nicht global sichtbar^^)

Also du sagst damit, dass du selbst auch prozedural programmierst?
In welchen Bereichen deiner Software, wird diese objektorientiert sein (und warum?), in welchen prozedural (und warum?)
Mindestes die Main, weils nicht anders geht^^
z.B. Mathematische Funktionen, die sind nun mal selten Objekte...Aber soweit es geht ist der Code OO
 
H

httpdigest

Tolle Antwort, @mihe7!
Sie zeigt sehr gut, dass OO eben auch etwas mit Abstraktion durch Polymorphie zu tun hat. Jetzt können die PostPolicies polymorh implementiert werden, womit man die Aufrufstelle von der konkret zu verwendenden Policy abstrahiert hat.
Ist ein schönes Beispiel, wie man mit OO dem hehren Ziel von Software Engineering, Code möglichst nur an wenigen Stellen ändern zu müssen, näher kommt. Klar kann man Polymorphie in prozeduralen Sprachen wie C auch über Function Pointer lösen (falls @knotenpunkt das gleich erwähnen möchte), aber die Function, die dann eine Implementierung einer Policy sein wird, benötigt ihrerseits ja auch Kontextinformationen, die statisch sind oder die sie sich von wo anders herholt oder injiziert bekommt und nicht immer mit jedem Aufruf mitgeschliffen werden sollten, weil das wieder den Nutzungscode abhängig von der Policy machen würde. Und dann sind wir beim Kapseln von Funktionen und Daten und sind bei... ja genau, OO!
Daraufhin kann man dann wieder erwidern: Ja, dann schleife ich eben ein Struct mit dem Aufruf mit, welches alle nötigen Daten für diese Funktion beinhaltet. Ja, das ist dann aber auch OO in Disguise: das Struct wäre dann nämlich eine Instanz einer Klasse.
 
K

knotenpunkt

Hey,

@mihe7

So hier muss ich wieder etwas weiter ausholen^^

Das was du beschreibst, kann ich syntaktisch eins zu eins mittels Funktionspointer (@httpdigest ) oder aber auch mit einem switch-case nachbilden.

Die Verwendung von polymorphen Klassen, Funktionspointern, oder switch-case-Konstruktionen verändert erstmal 0 am paradigma selbst.

Warum aber ist die swtich-case-Lösung die beste?

die Post-Policy (deine interface-lösung) reagiert je nach Typ unterschiedlich.
Mein switch-case(post-polcy-typ-as-integer) ganz genauso!.


Wenn ich die Post-Policy ändern möchte, dann muss ich den ganzen Typ austauschen.

Das funktioniert beim switch-case auch erstmal nicht anders.

Aber ich kann das switch-case jetzt umbauen in eine feingranularere IF-Konstruktion.

if(WetterAPI->tollesWetter() && ....){verwende folgende PostPolicy}
Diese API Abfrage passiert genau zu dem Zeitpunkt, wo ich auch die Post-Policy verwende, sprich es ist nicht nicht nur ein Konfigurat, sondern ein Teil des Algorithmus.

Und das ist mir ganz allgemein ein Problem in der OO. Dieser feste Zustand, die Konfiguration.


Aber um ganz genau zu sein, deine Post-Policy ist nur ein Wrapper um meine Prozedurale Programmierung.
Sie beschreibt mein Problem nicht in einer OO-Welt, sondern modularisiert nur meine prozedurale Welt.


Aber um nochmal zu deiner Post-Policy zurückzukommen.
Ok du hast jetzt 20 verschiedene Policies.

Du möchtest folgenden Batch-Prozess ausführen.

k;
for(-> 100k)
{
//jeder schleifenaufruf benötigt irgendwie eine andere policy
tmp=berechne benötigte policy
k->setPolicy(gemäß tmp)
k->doSth();
}

das ist doch krampf

warum nicht

k;
for(-> 100k)
{
//jeder schleifenaufruf benötigt irgendwie eine andere policy
tmp=berechne benötigte policy
k->doSth(tmp); // gemäß tmp, eventuell ein int wert, wird in doSth ein entsprechender algorithmus ausgeführt
}


beide for-schleifen machen exakt das gleiche, nur zweitere wird vermutlich schneller ausgeführt.
und ja in C++ gibts nicht ohne Grund zur Compile-Zeit festestehende Templates (generics) und den Hinweis
vtables (sprich polymorphe) Klassen zu vermeiden wo es nur geht.
//aber das soll jetzt nicht das Hauptthema hier sein


@mihe7 kannst du mir verraten, warum deine Konfigurationsklasse so viel mehr sinnvoller sein soll, als ein switch-case bzw. if, wo ich zur laufzeit feingranual den algorithmus flexibel bestimmen kann.

ja auch deine polymorphen klassen arbeiten zur laufzeit. Aber es ist geht Richtung unflexibel.
Da das Wort Konfiguration schon für sich alleine aussagt, da wird irgendwo was konfiguriert und das wird erstmal ne zeitlang gelassen.

ich binde mich mit jedem objekt das einen this-zeiger hat, erstmal an einen unflexiblen/festen state, wenn ich später auf diesem objekt ein doSth() ausführe.



Das nachfolgende ist dementsprechend Unsinn. Ein Prozeduraufruf macht aus eine Prozedur noch lange nichts OO-artiges, das ist völliger Unsinn jeglicher Definition nach.
warum?, in Java kann ich an eine Prozedur auch eine Wrapper-klasse von Int schicken etc pp,
so habe ich dann auch Daten mit Verhalten versendet.
Und genau das machen doch ActionObjects auch, bzw. Service-Klassen. Diese empfangen auch derartige Datensätze/Objekte^^

Und damit darfst du keinen globalen Zustand mehr haben (auch wenn global in diesem Fall auf ein Modul eingeschränkt ist, sondern musst es alles durchreichen.
Und das wäre auch die OO-Lösung: Dependency Injection (im einfachsten Fall mit Durchreichen).
Ok, kein globaler Zustand, wer ist aber dann verantwortlich dass die Daten an entsprechende Aktoren durchgereicht werden?


Aber Prozeduren (und damit auch Structs?) siehst du als einzelne Module an?
Ich glaube da haben wir uns etwas verhettert^^

Wie bekommst du denn den Struct Motorradmotor und den Struct Sonne zusammen, die beide einzelnen Modulen entsprechen sollen?
Das was du beschreibst, ist kein OO-Problem.
Ja das ist die Frage, wer kümmert sich darum, dass entsprechende Dinge, Daten, Objekte zusammenkommen?

Du kannst ein Struct rumreichen, klar, aber mit Objekten hast du eben die zu den Daten gehörenden Funktionen, darum geht es doch ^^
Funktionen welcher Art?
Und das ist die Frage.
Bei ADTS, abstrakten Datentypen akzeptiere ich es.
Aber bei allen anderen Datentypen, welche Art Funktionen hast du da, wenn du in deinem Programm Service-Klassen, etc pp einsetzt?


DATEN, bei OO injectest du Daten UND FUNKTIONEN auf diesen. Genau darum geht es doch.
und was machen diese FUNKTIONEN?^^

Eigentlich sind das alles Indizien, dass sie OO nutzen.
DI, Services, ActionObjekts SIND KEINE PP, es sind immer DATEN UND FUNKTIONEN - und mit einem ohne das andere kann man an der Stelle nichts anfangen.
wenn du services hast, dann sind die Funktionen denen die in die Service injecteten Objeten sehr spärlich.
Getter/Setter, vllt. noch ein paar objekteinschränkende Funktionen, wie setColor, welche aufpasst, dass keine falsche Farbe gesetzt wird, aber das wars doch schon?!



Wie sieht denn die PP-Variante aus? (Und denk dabei an das von oben, Sonnensystem ist nicht global sichtbar^^)
Diese injecteten Daten wie Motorradmotor und Sonne müssen ja irgendwo her kommen.
der Dependency-Injector-Manager muss diese ja irgendwie greifen können?^^
Wo bekommt Jener das her?

Was mache ich wenn ich mehrere Sonnen und Motorradmotore habe?
Was mache ich wenn erst zur Laufzeit bekannt wird, welche Sonne relevant ist?

Sprich der Motorradmotor hat über 7k Umdrehungen und im Spielchat schreibt jemand Sonne5
Erst dann soll die Abhängigkeit zur 5ten Sonne entstehen.
Oder ein Zufallsgenerator entscheidet welche Sonne relevant ist, zu dem Zeitpunkt wo sie relevant wird.

Wie würdest du das dann machen?




Soweit mal wieder



lg knotenpunkt
 
K

knotenpunkt

aber die Function, die dann eine Implementierung einer Policy sein wird, benötigt ihrerseits ja auch Kontextinformationen, die statisch sind oder die sie sich von wo anders herholt oder injiziert bekommt und nicht immer mit jedem Aufruf mitgeschliffen werden sollten, weil das wieder den Nutzungscode abhängig von der Policy machen würde. Und dann sind wir beim Kapseln von Funktionen und Daten und sind bei... ja genau, OO!
ok du hast das hier gekapselt, kannst dann aber auch nicht mehr wirklich im nutzungscode darauf reagieren

-> du wirst unflexibler



lg knotenpunkt
 
mrBrown

mrBrown

Das was du beschreibst, kann ich syntaktisch eins zu eins mittels Funktionspointer (@httpdigest ) oder aber auch mit einem switch-case nachbilden.

Die Verwendung von polymorphen Klassen, Funktionspointern, oder switch-case-Konstruktionen verändert erstmal 0 am paradigma selbst.
Nein, das lässt sich nicht alles gleichartig Nutzen.

Polymorphie: Du hast Context des Ausrufers und des Aufgerufenen (Parameter und Instanzvariablen) und kannst beliebig, sogar zur Laufzeit, neue Typen einführen.
Funktionspointern: Du hast nur den Context des Aufrufes (Parameter), hast aber keinen zu der Funktion gehörenden Kontext (kann man nachbauen, aber wenn man OO nachbaut, warum nicht gleich richtige Polymorphie?)
Switch: Du hast wieder nur den Context des Aufrufes, aber bist dazu noch völlig statisch. Die Menge der Typen ist zur Compilezeit festgelegt, jede Änderung erfordert eine neu kompilieren.

Warum aber ist die swtich-case-Lösung die beste?

die Post-Policy (deine interface-lösung) reagiert je nach Typ unterschiedlich.
Mein switch-case(post-polcy-typ-as-integer) ganz genauso!.


Wenn ich die Post-Policy ändern möchte, dann muss ich den ganzen Typ austauschen.

Das funktioniert beim switch-case auch erstmal nicht anders.

Aber ich kann das switch-case jetzt umbauen in eine feingranularere IF-Konstruktion.

if(WetterAPI->tollesWetter() && ....){verwende folgende PostPolicy}
Diese API Abfrage passiert genau zu dem Zeitpunkt, wo ich auch die Post-Policy verwende, sprich es ist nicht nicht nur ein Konfigurat, sondern ein Teil des Algorithmus.

Und das ist mir ganz allgemein ein Problem in der OO. Dieser feste Zustand, die Konfiguration.
Irgendwie scheint dir zu entgehen, dass das Austauschen der Post-Policy keine Änderungen an irgendeinem bestehendem Code erfordert, deine switch-case oder if-Lösung dagegen schon.
Die Konfiguration der Post-Policy kann vollständig aus dem Code herausgehalten werden, es kann in irgendeiner Datei festgelegt sein, welche Post-Policy benutzt wird.

Um bei deinem Beispiel zu bleiben: statt Wetter soll jetzt die Position der ISS benutzt werden.
In deinem Fall: Code umschreiben, neu kompilieren, ganze Anwendung deployen.
Im OOP-Fall: eine neue Klasse anlegen und *nur* diese kompilieren, diese *eine* Klasse deployen, *eine* Zeile in einer *Konfigdatei* anpassen - fertig.

Und das ist mir ganz allgemein ein Problem in der PP. Der feste Algorithmus, der es völlig unflexibel macht.


Du möchtest folgenden Batch-Prozess ausführen.

k;
for(-> 100k)
{
//jeder schleifenaufruf benötigt irgendwie eine andere policy
tmp=berechne benötigte policy
k->setPolicy(gemäß tmp)
k->doSth();
}

das ist doch krampf

warum nicht

k;
for(-> 100k)
{
//jeder schleifenaufruf benötigt irgendwie eine andere policy
tmp=berechne benötigte policy
k->doSth(tmp); // gemäß tmp, eventuell ein int wert, wird in doSth ein entsprechender algorithmus ausgeführt
}
abgesehen davon, dass obiges natürlich auch als k->doSth(tmp) schreibbar ist:
Was Code umfasst denn in beiden Fällen doSth?
Mit OOP: keine Verzweigung oder ähnliches, sondern nur ein Methodenaufruf, eine neue Policy bedeutet, eine neue(!) Klasse anzulegen
Mit PP: ein Switch mit 100(!) Fällen und eine harte Kopplung an alle einzelnen policys, eine neue Policy bedeutet, bestehenden(!) Code zu ändern.


Da das Wort Konfiguration schon für sich alleine aussagt, da wird irgendwo was konfiguriert und das wird erstmal ne zeitlang gelassen.
Konfiguration != fest, Konfiguration kannst du im Gegensatz zu deinem fest kompilierten Algorithmus zur Laufzeit beliebig austauschen.

ich binde mich mit jedem objekt das einen this-zeiger hat, erstmal an einen unflexiblen/festen state, wenn ich später auf diesem objekt ein doSth() ausführe.
Und du findest das binden an "this" unflexibeler, als das binden an doSth()?

warum?, in Java kann ich an eine Prozedur auch eine Wrapper-klasse von Int schicken etc pp,
so habe ich dann auch Daten mit Verhalten versendet.
Und genau das machen doch ActionObjects auch, bzw. Service-Klassen. Diese empfangen auch derartige Datensätze/Objekte^^
Wie gesagt: Wenn du Objekte als Prozedural bezeichnen willst, gerne. Dann verlang aber nicht, das irgendwer anders auch OOP==PP sagt ;)

Ok, kein globaler Zustand, wer ist aber dann verantwortlich dass die Daten an entsprechende Aktoren durchgereicht werden?
der lokale Zustand?

Ja das ist die Frage, wer kümmert sich darum, dass entsprechende Dinge, Daten, Objekte zusammenkommen?
Verrat du es mir doch? Für dich scheint das ja in PP kein Problem zu sein?

Funktionen welcher Art?
Und das ist die Frage.
Bei ADTS, abstrakten Datentypen akzeptiere ich es.
Aber bei allen anderen Datentypen, welche Art Funktionen hast du da, wenn du in deinem Programm Service-Klassen, etc pp einsetzt?
Die, die zu dem entsprechendem Typ gehören?
Auf diese Frage gibt es keine generische Antwort, die gibt es eben nur bei ADT.
Bei einer Post-Policy könnte das zB die Abfrage der Rechte sein.

und was machen diese FUNKTIONEN?^^
wenn du services hast, dann sind die Funktionen denen die in die Service injecteten Objeten sehr spärlich.
Getter/Setter, vllt. noch ein paar objekteinschränkende Funktionen, wie setColor, welche aufpasst, dass keine falsche Farbe gesetzt wird, aber das wars doch schon?!
Dre Satz ergibt nicht wirklich Sinn...
Es sind *alle* Funktionen, die nicht mehrere verschiedene, getrennte Objekte umfassen.
Bei einer Post-Policy könnte das zB die Abfrage der Rechte sein.

Diese injecteten Daten wie Motorradmotor und Sonne müssen ja irgendwo her kommen.
der Dependency-Injector-Manager muss diese ja irgendwie greifen können?^^
Wo bekommt Jener das her?

Was mache ich wenn ich mehrere Sonnen und Motorradmotore habe?
Was mache ich wenn erst zur Laufzeit bekannt wird, welche Sonne relevant ist?
bei OO entscheidet sich das immer erst zur Laufzeit, das ist doch einer der zentralen Punkte...

Wenn du mehrere Sonnen und Motorradmotoren hast, hast du entweder mehrere vorgesehen, und es gibt zu einem Zeitpunkt mehrere, oder es gibt mehrere in unterschiedlichen Kontexten, aber pro Kontext eben nur einen.
Diesen Kontext kennt man natürlich, und dementsprechend erstellt man an irgendeiner Stelle passende Objekte bzw lässt sie erstellen.

Sprich der Motorradmotor hat über 7k Umdrehungen und im Spielchat schreibt jemand Sonne5
Erst dann soll die Abhängigkeit zur 5ten Sonne entstehen.
Oder ein Zufallsgenerator entscheidet welche Sonne relevant ist, zu dem Zeitpunkt wo sie relevant wird.
Motoradmotor hat einen Sonnen-Proxy. Ändert sich die Sonne des Kontextes, ändert sich der Proxy entsprechend.
Weder Motor noch Sonne müssen dabei etwas über den Kontext wissen.
Mit allen Handelsüblichen DI-Frameworks in Java abdeckbar ;)
 
mihe7

mihe7

Das was du beschreibst, kann ich syntaktisch eins zu eins mittels Funktionspointer (@httpdigest ) oder aber auch mit einem switch-case nachbilden.
Mit Function Pointer ja. Dann sind wir bei OO. Mit switch-Statements geht das nur statisch. Und "statisch" ist gerade nicht "dynamisch" :)

kannst du mir verraten, warum deine Konfigurationsklasse so viel mehr sinnvoller sein soll, als ein switch-case bzw. if, wo ich zur laufzeit feingranual den algorithmus flexibel bestimmen kann.
Du hast eine Abhängigkeit in Richtung Implementierungsdetail, ich nicht.

Die Sache ist doch ganz einfach: es wäre irgendwie ungünstig, wenn jedes Programm ein switch-Statement enthalten würde, das alle Druckermodelle dieser Welt kennt. Vom Aufwand mal abgesehen, würde dieses Programm mit neuen Druckermodellen ggf. nicht mehr funktionieren.

Die Prozedur, die das switch-Statement enthält, muss alle Prozeduren kennen, die dort aufgerufen werden. Willst Du eine neuen Drucker (oder eine neue Policy), musst du die switch-Prozedur ändern, damit der Drucker (die Policy) überhaupt berücksichtigt werden kann. Das ist nicht flexibel (s. o.), sondern für die Tonne (s. o.), auch weil man ständig Code ändern muss, der noch dazu mit der eigentlichen Aufgabe nichts zu tun hat.

Da das Wort Konfiguration schon für sich alleine aussagt, da wird irgendwo was konfiguriert und das wird erstmal ne zeitlang gelassen.
Und? Weil ich mir nach einem Jahr einen neuen Drucker kaufe, soll ich gleich eine neue Tabellenkalkulation und Textverarbeitung und Editoren und ... mitkaufen, weil dort ein switch-Statement verwendet wurde?!?
 
A

AndiE

kannst du mir verraten, warum deine Konfigurationsklasse so viel mehr sinnvoller sein soll, als ein switch-case bzw. if, wo ich zur laufzeit feingranual den algorithmus flexibel bestimmen kann.
Wie soll das denn praktisch funktionieren. Wie will ich denn mit einem switch oder if festlegen, wer welchen Raum benutzen darf? Zuerst mache ich ein "switch(raum)" und dann z.B. bei "case 108:" eine "if-Abfrage" nach den Personalnummern? Um dann passgenau nur genau ausgewählten Leuten den Zugang zu gewähren? Wenn die Nr. 12345 9 Räume betreten darf, brauche ich dann nicht auch 9 abfragen. Wie teste ich, dass das auch funktioniet, und der Programmierer nicht irgendwo 12354 eingeben hat? Und wenn ein Professor neu ernannt wird?
 
K

knotenpunkt

hey,

Nein, das lässt sich nicht alles gleichartig Nutzen.

Polymorphie: Du hast Context des Ausrufers und des Aufgerufenen (Parameter und Instanzvariablen) und kannst beliebig, sogar zur Laufzeit, neue Typen einführen.
Funktionspointern: Du hast nur den Context des Aufrufes (Parameter), hast aber keinen zu der Funktion gehörenden Kontext (kann man nachbauen, aber wenn man OO nachbaut, warum nicht gleich richtige Polymorphie?)
Switch: Du hast wieder nur den Context des Aufrufes, aber bist dazu noch völlig statisch. Die Menge der Typen ist zur Compilezeit festgelegt, jede Änderung erfordert eine neu kompilieren.
und ja genau das ist eben mein Problem, der Kontext des Aufgerufenen. Das macht die Sache ja so unflexibel
Ausserdem:
Wie entscheide ich welche Daten ich als Instanzvariable in den Aufgerufenen binde und welche Daten ich schön flexibel von aussen hineinreiche?
Warum nicht gleich die größt möglichste Flexibilität nehmen und alle Daten von auẞen hineingeben?


Irgendwie scheint dir zu entgehen, dass das Austauschen der Post-Policy keine Änderungen an irgendeinem bestehendem Code erfordert, deine switch-case oder if-Lösung dagegen schon.
Die Konfiguration der Post-Policy kann vollständig aus dem Code herausgehalten werden, es kann in irgendeiner Datei festgelegt sein, welche Post-Policy benutzt wird.

Um bei deinem Beispiel zu bleiben: statt Wetter soll jetzt die Position der ISS benutzt werden.
In deinem Fall: Code umschreiben, neu kompilieren, ganze Anwendung deployen.
Im OOP-Fall: eine neue Klasse anlegen und *nur* diese kompilieren, diese *eine* Klasse deployen, *eine* Zeile in einer *Konfigdatei* anpassen - fertig.

Und das ist mir ganz allgemein ein Problem in der PP. Der feste Algorithmus, der es völlig unflexibel macht.
Das einzige was ich mit funktionispointern/polymorphe Klassen erreiche ist folgendes:
ich kann zur Laufzeit neu hinzukompilierte Programmstücke ins laufende Programm einpflanzen. (Da gebe ich dir vollkommen recht)
Wenn ich diese Praxis aber nicht unbedingt brauche, dann kann ich auch darauf verzichten.

Bei dem Switch-Case Szenario gebe ich dir auch recht, dass ich im Falle eines neuen Falls an entsprechender Stelle im Code eine Änderung im Sinne von einer Erweiterung vornehmen muss.
Aber ganz ehrlich, irgendwo muss festgelegt werden, welche in unserem Fall hier jetzt die Postpolicy aufgerufen wird. Ein Switch-Case geht jetzt etwas in die Richtung fixer Konfigurationsstate (wo man wirklich überlegen könnte das durch die performance-schlechtere Alternative bestehend aus polymorphen Klassen zu ersetzen).

Der Entscheidungsstate, also welche Postpolicy aufgerufen wird ist im Falle eines Switch-Case über eine switch(variable) festgelegt, im Falle von polymorphen Klassen eben postpolicy= ausgesuchtePostpolicy;

Beides setzt vorraus, dass vornherein entschieden worden ist, welche Postpolicy verwendet wird. Diese Entscheidung wird in irgendeinem Kontext fix abgespeichert. (fix im Sinne von, an dem Kontext wird nicht nach belieben rumgespielt. -> dadurch entsteht ne gewisse unflexibilität)


Möchte ich aber jetzt aus einem Request/Call/Whatever heraus entscheiden, welche Postpolicy verwendet wird, dann verzichte ich doch auf so nen festen state.

Der Request wird abgearbeitet und währenddessen wird entschieden welche Postpolicy relevant ist. Und das ist für mich hochdynamisch und schön prozedural.

Wie seht ihr das?


abgesehen davon, dass obiges natürlich auch als k->doSth(tmp) schreibbar ist:
Was Code umfasst denn in beiden Fällen doSth?
Mit OOP: keine Verzweigung oder ähnliches, sondern nur ein Methodenaufruf, eine neue Policy bedeutet, eine neue(!) Klasse anzulegen
Mit PP: ein Switch mit 100(!) Fällen und eine harte Kopplung an alle einzelnen policys, eine neue Policy bedeutet, bestehenden(!) Code zu ändern.
ja gut ich habe 100te postpolicys.......... für was?
Die postpolicys für sich alleine stehend sind doch wertlos

Klar das Switch-Case ist hier jetzt vereinfacht. Wie bereits oben geschrieben, soll nicht nur switch(variable) entscheiden welche postpolicy verwendet wird, sondern if(ziemlich viel) -> postpolicy


Konfiguration != fest, Konfiguration kannst du im Gegensatz zu deinem fest kompilierten Algorithmus zur Laufzeit beliebig austauschen.
vorrausgesetzt man möchte das.
Außerdem: ja es ist nicht fix..... mir gehts aber nicht darum hin und wieder mal was auszutauschen sondern feingranular zur laufzeit zu bestimmen was gerade Sache ist^^.....
Gleichen Konfigurationsstate den ich über viele calls hinweg verwende - zwar austauschen könnte -, ist für mich ein starres Gebilde.

Und du findest das binden an "this" unflexibeler, als das binden an doSth()?
Eine Gegenfrage beantwortet nicht meine Frage^^
dosth(blub, blab) bekommt zur Laufzeit entsprechende Daten (oft auch unterschiedliche Daten) und verhält sich entsprechend.
this wird vermutlich öfters gleiche daten (damit meine ich die Kontextdaten) haben und macht das ganze somit starr
falls this für jeden call bei this.dosth() andere daten hat, dann sind wir wieder bei meinen ActionObjects^^


der lokale Zustand?
das musste mir näher erklären, also was du damit meinst.

Verrat du es mir doch? Für dich scheint das ja in PP kein Problem zu sein?
Naja lch hole ich mir die Daten via einer anderen prozedur, die auf entsprechende Daten Zugriff hat.
Ob das dabei global oder über eine graph-verästelung oder Datenbank oder über whatever funktioniert spielt dabei keine Rolle.
(Das wichtige dabei ist zudem: ich hole mir in eine Hauptprozedur alle relevanten Daten um dann hier den Algorithmus zentral zu steuern.... Klar wenn ich den Algorithmus auf Unterprozeduren aufteilen kann, dann werde ich das natürlich machen)

Die, die zu dem entsprechendem Typ gehören?
Auf diese Frage gibt es keine generische Antwort, die gibt es eben nur bei ADT.
Bei einer Post-Policy könnte das zB die Abfrage der Rechte sein.
Naja ne Rechteabfrage bedeutet also du machst nen GetDaten-Aufruf.

Und von wo wird das aufgerufen?. Von einem Serviceobjekt nehme ich an?
-> Prozedurale Programmierung. Die Haupt-Programmlogik wird an zentraler Stelle verarbeitet.

Mich würde interessieren wie bei dir nen DoSth-Aufruf aussieht, der etwas komplexer ist.

Mit Function Pointer ja. Dann sind wir bei OO. Mit switch-Statements geht das nur statisch. Und "statisch" ist gerade nicht "dynamisch" :)
An der Stelle nochmal: Funktionspointer sind nicht objektorientiert.
Ja ich arbeite hier polymorph und zur Laufzeit Code austauschend.
Das hat aber mit der Objektorientierung im aAlgemeinen erstmal gar nichts zu tun.

Nur dadurch, dass ich polymorphe Klassen verwende, bin ich auch noch lange nicht objektorientiert.


Die Prozedur, die das switch-Statement enthält, muss alle Prozeduren kennen, die dort aufgerufen werden. Willst Du eine neuen Drucker (oder eine neue Policy), musst du die switch-Prozedur ändern, damit der Drucker (die Policy) überhaupt berücksichtigt werden kann. Das ist nicht flexibel (s. o.), sondern für die Tonne (s. o.), auch weil man ständig Code ändern muss, der noch dazu mit der eigentlichen Aufgabe nichts zu tun hat.
Irgendwo muss entschieden werden, welcher Drucker verwendet wird.
Wo wird das bei dir entschieden?

Wie soll das denn praktisch funktionieren. Wie will ich denn mit einem switch oder if festlegen, wer welchen Raum benutzen darf? Zuerst mache ich ein "switch(raum)" und dann z.B. bei "case 108:" eine "if-Abfrage" nach den Personalnummern? Um dann passgenau nur genau ausgewählten Leuten den Zugang zu gewähren? Wenn die Nr. 12345 9 Räume betreten darf, brauche ich dann nicht auch 9 abfragen. Wie teste ich, dass das auch funktioniet, und der Programmierer nicht irgendwo 12354 eingeben hat? Und wenn ein Professor neu ernannt wird?
Die Daten liegen natürlich nicht so im Code herum, sondern bspw. in einer Datenbank.
Entsprechende Algorithmen kann ich auch im Prozeduralen Stil schön modularisiert beherrschbar machen^^
Auch wenn ich jetzt statt nem if-else, switch-case etc pp polymorphe Klassen verwende, ist das nicht zwangsläufig objektorientiert.


Vllt. habe ich mich mit den switch-case/if(ziemlich vieles) VS polymorphe Klassen etwas zu weit aus dem Fenster gelehnt.
ABER im Grunde ist beides das gleiche und zweiteres nicht zwangsläufig objektorientiert.
Bei ersterem bin ich aber wesentlich flexibler, da ich aus dem Algorithmus heraus entscheide was Sache ist.
Zweiteres bedingt fast immer eine Vorkonfiguration und ist somit starr
Sieht man Zweiteres als Wrapper für Ersteres an (Naja ich habe ja nen prozeduralen Code hier reingeschrieben. Jemand hat dann die Postpolicy ins Spiel gebracht und meinen Code da rein gewrappt), dann habe ich eigentlich nichts verändert, sondern eben nur Code in irgend einen cool-aussehenden Code hineingewrappt.




Soweit mal wieder dazu


lg knotenpunkt
 
mihe7

mihe7

An der Stelle nochmal: Funktionspointer sind nicht objektorientiert.
Ja ich arbeite hier polymorph und zur Laufzeit Code austauschend.
Das hat aber mit der Objektorientierung im aAlgemeinen erstmal gar nichts zu tun.
Das ist der Kernpunkt von OO. Mir drängt sich allmählich der Eindruck auf: "Ja, ich arbeite polymorph, ich begrenze den Zugriff auf Daten, aber OO - Gott bewahre, nein OO ist das nicht, weil nicht sein kann, was nicht sein darf".

Bei ersterem bin ich aber wesentlich flexibler, da ich aus dem Algorithmus heraus entscheide was Sache ist.
Zweiteres bedingt fast immer eine Vorkonfiguration und ist somit starr
Wir drehen uns im Kreis.

Natürlich muss die Anwendung irgendwie "konfiguriert" werden. Du schreibst die Konfiguration fix in den Code. Andere machen den entsprechenden Code flexibel und konfigurieren ihn an anderer Stelle.

dann habe ich eigentlich nichts verändert, sondern eben nur Code in irgend einen cool-aussehenden Code hineingewrappt.
Du hattest gar keinen Code geliefert, insofern habe ich da auch nichts "hineingewrappt".

Geändert hat sich dadurch die Tatsache, dass der Code flexibel konfigurierbar ist. Ich muss dort nichts mehr ändern, um eine andere Policy verwenden zu können.
 
mrBrown

mrBrown

und ja genau das ist eben mein Problem, der Kontext des Aufgerufenen. Das macht die Sache ja so unflexibel
Ausserdem:
Wie entscheide ich welche Daten ich als Instanzvariable in den Aufgerufenen binde und welche Daten ich schön flexibel von aussen hineinreiche?
Warum nicht gleich die größt möglichste Flexibilität nehmen und alle Daten von auẞen hineingeben?
Du musst deine Domäne vernünftig designen. Die Entscheidung, ob Instanzvariable oder Parameter, ergibt sich in so gut wie jedem Fall aus der Domäne.

Deine "Flexibilität" (die in OO nicht verloren geht), ist bei dir im wesentlichen ein Aufgeben aller sinnvollen Empfehlung für Programmstruktur. Kann man machen, in den letzten ~50 Jahren hat sich aber das Gegenteil durchgesetzt.

Ein Switch-Case geht jetzt etwas in die Richtung fixer Konfigurationsstate
Und das ist für mich hochdynamisch
Der Widerspruch fällt dir schon so ein bisschen auf?

Klar das Switch-Case ist hier jetzt vereinfacht. Wie bereits oben geschrieben, soll nicht nur switch(variable) entscheiden welche postpolicy verwendet wird, sondern if(ziemlich viel) -> postpolicy
Also wird der Code noch unübersichtlicher? Du hast jetzt 100 komplexe, eng verknüpfte Bedingungen - und das ist dir lieber als 100 vollkommen unabhängige Klassen, die jeweils genau eine Bedingung prüfen?

Außerdem: ja es ist nicht fix..... mir gehts aber nicht darum hin und wieder mal was auszutauschen sondern feingranular zur laufzeit zu bestimmen was gerade Sache ist^^.....
Gleichen Konfigurationsstate den ich über viele calls hinweg verwende - zwar austauschen könnte -, ist für mich ein starres Gebilde.
Und dir ist bisher nicht aufgefallen, dass es nichts starreres als ein Switch-Case gibt? Du weißt aber schon, was ein Switch ist?

Vllt. habe ich mich mit den switch-case/if(ziemlich vieles) VS polymorphe Klassen etwas zu weit aus dem Fenster gelehnt.
ABER im Grunde ist beides das gleiche und zweiteres nicht zwangsläufig objektorientiert.
Bei ersterem bin ich aber wesentlich flexibler, da ich aus dem Algorithmus heraus entscheide was Sache ist.
Zweiteres bedingt fast immer eine Vorkonfiguration und ist somit starr
Also, um deine Aussagen einmal umzuformulieren:

Im Algorithms hart kodiert haben, was passiert = flexibel
Einen konfigurierbaren Algorithmus haben, den man von außen verändern kann = unflexibel

Vielleicht sollten wir uns auf eine Definition von "flexibel" einigen, du scheinst eine sehr merkwürdige zu verwenden...
 
Thema: 

OO ist gescheitert

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben