OO ist gescheitert

?

Ist OO (definiert nach Alan Key) gescheitert?

  1. JA

  2. NEIN

Das Ergebnis kann erst nach Abgabe einer Stimme betrachtet werden.

Diskutiere OO ist gescheitert im Softwareentwicklung Forum; Wenn ich mir eine "boolean access ( string room, string pin)" vorstelle, dann gibt diese Funktion an, ob die Person mit der pin den Raum betreten...

  1. AndiE
    AndiE Aktives Mitglied
    Wenn ich mir eine "boolean access ( string room, string pin)" vorstelle, dann gibt diese Funktion an, ob die Person mit der pin den Raum betreten darf. Um das zu gewährleisten, würde ich eine XML erstellen, wo ich dann menschenlesbar die Zutrittsberechtigungen reinschreibe. Nun stellt so eine XML aber eine hierachische Objektstruktur dar. Da ist dann wieder das O-Wort. Die Methode würde dann nämlich "boolean Room.access(string pin) heißen.
    In rein PP gibt es aber maximal Arrays und Records. Theoretisch könnte ich in PP mit CSV eine Datei auslesen, die dann identische Tupel von Daten hat, die aber nicht zwingend strukturiert sind. Da kann es dann sein, dass der letzte Datensatz zeigt, dass die Person Zugriff hat. Änderungen sind hier schwer machbar, im Gegensatz zur XML.
     
  2. AndiE
    AndiE Aktives Mitglied
    Geht es hier noch weiter?
     
  3. knotenpunkt
    knotenpunkt Neues Mitglied
    hey,

    Die knotenpunktschen Mühlen mahlen langsam, aber sie mahlen.
    Ja es geht weiter^^

    Nein das ist nicht der Kernpunkt von OO. Siehe anfängliche Definition.

    Die Frage ist, was heißt Konfiguration?
    Sowie ihr es versteht: Bspw. die Datenbankzugangsdaten für eine Datenbanklasse.
    Oder die Farbe der Sonne, von der die Temperatur magischerweise mit meinem Motorradmotor verbunden ist^^

    Was ist aber wenn sich derartige "Konfigurationen" erst zur Laufzeit gesetzt werden sollen?
    Und zwar nicht perstistent gesetzt werden sollen.

    Je nach Request, nach Kontextaufruf, ist meine Sonne mal blau mal gelb mal grün usw......
    Abhängig davon was bei call_func(par1, par2, par3) par1 par2 und par3 ist, möchte ich eine andere Konfiguration vorliegen haben. DAS ist hochflexibel und nicht starr. So meine ich das!



    Ja doch ein Pseudocode habe ich schon hingeschrieben. Und davon ausgehend hast du meinen Pseudocode als Grundlage genommen.


    Und was bringt ein Austausch von einer Policy in eine andere, wenn folgendes gilt?:

    In meinem code steht:

    //Markierung I
    {
    if(par1&& par2 || par3 .......){do_sth1(parX);}
    if(...){dot_sth2(parX);}
    //also es wird zur Laufzeit hochdynamisch/hochflexibel entschieden was passieren soll.
    }

    Was du gemacht hast, ist folgendes:

    etwasAustauschbares // das ist dein Wrapper
    {
    if(par1&& par2 || par3 .......){do_sth(parX);}
    if(...){dot_sth2(parX);}
    //also es wird zur Laufzeit hochdynamisch/hochflexibel entschieden was passieren soll.
    }

    etwasAustauschbares2
    {
    // was soll hier dann bitte stehen?
    //wo brauche ich noch ne weitere policy....... ich habe ja alles oben in meinen if-kaskaden abgedeckt!
    //hochflexibel wohlgemerkt!
    }


    stattdessen würdest du eventuell folgendes wollen:
    die do_sth()-Einheiten werden bei dir zu den etwasAustauschbarenObjekten.

    //Markierung II
    if(par1&& par2 || par3 .......)
    {
    callObj= do_sth1_OBJ();
    }
    if(...)
    {
    callOBj=do_sth2_OBJ();
    }

    und später dann callOBj->action(X);


    //problem welches in dieser Transformation auftaucht:
    In Markierung I könnte es sein, dass sowohl do_sth1(X) als auch do_sth2(X) aufgerufen wird.
    In Markierung II ist das so nicht mehr möglich. Das wäre ein weiterer negativer Seiteneffekt.

    Aber auf was ich eigentlich hinaus möchte, ist das folgende:


    Markierung II wird dann genommen, wenn etwas länger konfiguriert sein sollte, sprich diese ifs sehr selten aufgerufen werden. Was ist aber wenn diese ifs bei jedem CALL neu abgearbeitet werden sollen.
    Dann ist doch Markierung II offensichtlich fehl am Platz.
    Ich würde so bei jedem CALL sinnloserweise "neukonfigurieren".

    Das macht II zwar nicht unflexibel, da es ja transformiert (fast) das gleiche ist wie I.
    Aber es zeigt einen unperformanteren Programmaufbau und viel Overhead-Programmierarbeit.

    Und sollte nicht bei jedem CALL das if neuausgewertet werden bei II, dann kann ich im übertragenem Sinne schon davon sprechen, dass OO unflexibler ist, da ich mich in diesem Falle auf eine starre Konfiguration verlasse, die selten geändert wird.


    Da ich aber von Top to Down programmiere und nicht Bottom-Up, ist das halt nicht so cool.
    Ausserdem möchte ich ja mein Programm auch zu jeder Zeit anpassen/erweitern können, ohne jedes mal alles refactoren zu müssen^^



    Ich habe da ja etwas mehr dazu geschrieben^^.
    Den Widerspruch der da vermeintlich zu erkennen ist, soll ja auch nur auf den ersten Blick so zu erkennen sein.
    Wenn man weiterliesst, dann hebt sich dieser auf.
    Bei mir bleibt der Widerspruch nicht starr und fix stehen. Ich schreibe auch im deutschen nicht objektorientiert, sondern ich schreibe prozedurale Texte. Die sind flexibel!^^


    Was bringen mir 100 unabhängige Klassen, von denen jede sein eigenes Brot bäckt?
    Irgendwo müssen die Klassen wieder zusammengeführt werden. Siehst du das nicht auch so?

    An der Stelle möchte ich natürlich sagen, dass ich Komponenten durchaus liebe. Hier trenne ich dann sehr wohl und es ist nicht mehr überall alles zugreifbar. Aber ich mache das nicht auf atomarer Ebene, wo jedes Staubkörnchen ein eigenes Biotop darstellen muss.

    Ausserdem greife ich im prodeduralen auch nicht direkt auf irgendwelche Speicher, Daten zu, sondern gehe da immer serviceorientiert über eine Prozedur. Woher meine angefragte Prozedur seine Daten bekommt um mir meine Anfrage zu beantworten ist mir dabei egal. Es kann sich dabei um ein Speicherfeld im Hauptspeicher handeln. Es kann sich um einen Datenbankeintrag handeln. Es kann sich um ein Wert handeln, den die aufgerufene Prozedur über einen REST-Call oder Whatever bekommt.





    Ein Switch ist schnell in ein IF-ELSE umgeformt und die Entscheidungen die das IF-ELSE trifft hängen hochflexibel vom aufgerufenem Kontext ab!
    So werden die Daten hineingegeben und das IF-ELSE reagiert je nachdem was die Parameter so an Daten beinhalten ENTSPRECHEND UND NICHT IMMER GLEICH, wie es bei einem starren vorkonfiguriertem objektorientierten Gebilde wäre.

    Siehe dieses Antwortschreiben^^
    Ein konfigurierbarer Algorithmus wird nur selten umkonfiguriert. Und das macht die Sache im übertragenem Sinne unflexibler!


    Und jetzt kommt noch die Uhrzeit hinzu und vieles mehr.......

    boolean access_room(roomId, roomPin, roomPin_benotigt, time, ......)
    {
    if(.......) return true;
    return false;
    }

    Das Interessante dabei ist: es ist sowas von egal wie die prozedur intern arbeitet UND der Aufrufer braucht auch keine Instanz vom ROOM mit der roomId haben.
    Ich kann die Prozedur zudem von überall aufrufen.

    Bspw. wenn mein Motorradmotor für den Turbomodus wissen möchte, ob der Room mit der ID 7 aktuell accessable ist.

    access_room(7,0,false, TIME,.....);

    Der Motorradmotor braucht übrigens keine Instanz von Raum 7 haben.



    Soweit mal wieder


    lg knotenpunkt
     
  4. mrBrown
    mrBrown Super-Moderator Mitarbeiter
    Doch, Polymorphie ist der Kernpunkt der Definition.
    Messages ist die Art von Polymorphie, die in der Sprache, von der die Definition abstammt, umgesetzt ist.

    Wie kommst du immer auf die Idee, dass die Konfiguration irgendwie starr und perstistent hinterlegt ist? Das ist sie üblicherweise nicht.
    DER zentrale Punkt von OOP ist Late Binding, das genaue Gegenteil von statischer Konfiguration. (und btw, auch wir meinen mit Konfiguration mehr als irgendwo hinterlegte Strings).

    Das was du meinst, versteht dagegen niemand (außer ein paar theoretischen Informatikern...) als "Konfiguration" des Programms.

    Wo kommen eigentlich deine Werte her? Hast du bisher noch nie wirklich dargelegt (also abseits von "hochflexibel", was bei dir wohl sowas wie "viele if" heißt...)

    Das ist schon per Definition nicht "hochflexibel". Eine hart programmierte Bedingung ist nicht flexibel. Und ja, ein par1&& par2 || par3 ....... ist hart programmiert!


    Nein, würde er nicht.
    (Ich kann dir versprechen, in @mihe7's Code wirst du keine solchen Ausprogrammierten if-Kaskaden finden)



    Also: du möchtest dir keine Gedanken über deine Software machen sondern einfach irgendwo programmieren und am Ende alle Möglichkeiten haben.

    Soll ich dir was verraten?
    Das hat nie funktioniert. Das funktioniert nicht. Das wird nie funktionieren.


    Nein. if-else ist nicht flexibel. Dort steht hart zur Compilezeit die Bedingung, das ist das genaue Gegenteil von Flexibel.
    Also:
    Ein konfigurierbarer Algorithmus ist unflexibel, weil man ihn nicht umkonfiguriert.
    Aber ein nicht-konfigurierbarer Algorithmus ist flexibel, weil ... äh warum eigentlich?

    Ersetz ID mal mit Referenz (Die ID ist ja nichts anderes als eine Referenz auf den Raum?) und Instanz mal mit Referenz (das was man in z.B. Java hat, ist die Referenz auf die Instanz).

    Fällt dir was auf?

    Falls nein: Wie kommt denn die '7' in den Motorradmotor? (Und warum bestimmt der Motor, das er keine Pin braucht?)
     
    mihe7 und Meniskusschaden gefällt das.
  5. mrBrown
    mrBrown Super-Moderator Mitarbeiter
    Ein kleiner (oder größerer) Tipp am Rande: Beschäftige dich doch mal Grundlegend mit Software Engineering.
    Verschaff dir mal einen geschichtlichen Überblick von den Anfängen der Software-Entwicklung bis heute, was es da so für Probleme und Lösungen gab.


    Das, was man von dir so liest, erweckt den Eindruck, dass du dich mit sowas noch nie wirklich beschäftigt hast und auch noch nicht mit größeren Programmen gearbeitet hast.
     
  6. mihe7
    mihe7 Bekanntes Mitglied
    Lies Dir mal http://www.purl.org/stefan_ram/pub/doc_kay_oop_en durch.

    Du führst einen starren Satz von Bedingungen ein, auf den die Anwendung an dieser Stelle zur Laufzeit reagiert, um den Eindruck von Flexibilität zu erwecken.

    Das ist wie bei einer Fernbedienung für den Fernseher: da habe ich Knöpfe mit if-Abfragen: if Knopf 1 gedrückt, then sende(CodeX) else if Knopf 2 gedrückt, then sende(Code Y), else if Knopf4 AND Knopf5 AND NOT Knopf6 gedrückt, sende(CodeZ) gesendet usw.

    Jetzt kann ich sagen: hey, das ist ja ganz schön flexibel: die ganzen Knöpfe, die ich da drücken kann und was dann am Fernseher alles passiert.

    Wie flexibel so eine Fernbedienung ist, sieht man in vermutlich jedem zweiten Wohnzimmer, wo gefühlte 25 Fernbedienungen auf dem Tisch liegen, weil keine (vernünftig) in der Lage ist, den TV, Receiver, Heimkino-Anlage, Rollos, usw. zu bedienen.

    Vermutlich kommt jetzt der Einwand von Universalfernbedienungen. Die machen das Gesamtsystem tatsächlich etwas flexibler - aber nicht aufgrund ihrer if-Abfragen, sondern weil eine Fernbedienung (ein Objekt) über einen dummen Kommunikationskanal Nachrichten (hört, hört) mit dem Fernseher (ein anderes Objekt) "austauscht" und weder die Fernbedienung, noch der Fernseher Internas voneinander wissen müssen. Es reicht, wenn die Schnittstelle bekannt ist.
     
    AndiE und mrBrown gefällt das.
  7. AndiE
    AndiE Aktives Mitglied
    Das überzeugt mich nicht. Angenommen ich habe ein Uni, die eine Anzahl Gebäude enthält und ich werde beauftragt, eine Software zu schreiben, die den Zugang der Personen zu den Räumen verwaltet. Macht es da Sinn, dass der Programmierer die Zugangsregeln verwaltet? Ist es nicht entschieden sinnvoller, wenn ich dem Kunden, in diesem Fall die Institutsverwaltung, die Möglichkeit gebe, dies zu verwalten? Ich denke schon. Da die Räume aber in sich identisch sind, ist es doch schlau, eine Vorlage zu klonen. Da sind wir bei der Objektabbildung einer Klasse. Hier weiß der Raum, wer ihn betreten darf und gibt demjenigen die Erlaubnis. So wie ein Pförtner. Damit sind wir bei der Phrase: X will in Raum Y eintreten. Darf er das?" Und die Regeln dafür liegen in irgendwelchen Datenstrukturen und nicht in Strukturen. Das ist doch wahrhaftige Flexibilität oder?
     
    mihe7 gefällt das.
  8. Meniskusschaden
    Meniskusschaden Bekanntes Mitglied
    Dann solltest du diese anfängliche Definition vielleicht mal präzisieren, denn sie ist viel zu unscharf, um als Basis für eine so lang laufende Diskussion zu dienen. Hier ist ein Teil deiner Definition:
    Was meinst du nun beispielsweise mit "OO ist nicht Polymorphy"? Soll das heissen, OO ist nicht identisch mit Polymorphie? Da stimme ich dir zu. Es ist nicht dasselbe. Ein Auto ist kein Motor.
    Oder soll es bedeuten, dass Polymorphie kein essentieller Bestandteil von OO ist? Da würde ich widersprechen. Ein Auto ohne Motor ist nicht sehr erfolgversprechend.

    An diesem Punkt waren wir aber bereits vor sehr vielen Beiträgen und trotz vieler, langer Texte gab es eigentlich schon lange keine neuen Aspekte mehr - nur kaum nachvollziehbare Behauptungen darüber, was nun starr oder flexibel sei. Vielleicht solltest du auch mal eine greifbare Definition deiner Vorstellung von Flexibilität liefern. Hier ist mal ein kleines lauffähiges OO-Beispiel. Jedes Tier weiß selbst, wie es sich bewegen muß, kann sein Bewegungsverhalten bei Bedarf aber auch ändern. Wie würde dein PP-Pendant dazu denn aussehen?
    Code (Java):
    public class Zoo {

        public static void main(String[] args) {
            Dog hasso = new Dog("Hasso");
            Animal[] animals = {hasso, new Dog("Bello"), new Fish("Fridolin"), new Fish("Nemo") };
            for (Animal animal : animals) {
                animal.move();
            }
            hasso.jumpIntoWater();
            System.out.println();
            for (Animal animal : animals) {
                animal.move();
            }      
        }
    }

    interface MotionStrategy {
        public void move();
    }

    class Running implements MotionStrategy {
        public void move() {
            System.out.println("läuft");
        }
    }

    class Swimming implements MotionStrategy {
        public void move() {
            System.out.println("schwimmt");
        }
    }

    abstract class Animal {
        private String name;
        MotionStrategy motionStrategy;
     
        public Animal(String name, MotionStrategy motionStrategy) {
            this.name = name;
            setMotionStrategy(motionStrategy);
        }
     
        public void setMotionStrategy(MotionStrategy motionStrategy) {
            this.motionStrategy = motionStrategy;
        }
     
        public void move() {
            System.out.print(name + " ");
            motionStrategy.move();
        }
    }

    class Dog extends Animal {
     
        public Dog(String name) {
            super(name, new Running());
        }
     
        public void jumpIntoWater() {
            motionStrategy = new Swimming();
        }
    }

    class Fish extends Animal {
     
        public Fish(String name) {
            super(name, new Swimming());
        }
    }
     
  9. knotenpunkt
    knotenpunkt Neues Mitglied
    hey,

    Nein das sehe ich nicht so, Polymorphie ist vllt. ein gutes Werkzeug, um die Konzepte der OO umzusetzen, jedoch das Werkzeug an sich, also die Polymorphie, ist nicht die OO.



    Mach doch mal ein Beispiel .
    In der Regel ist doch davon auszugehen, dass konfigurierte Objekte in der OO einen längeren Zeitraum existieren und nicht nur für die Dauer eines Requests, oder wie siehst du das?



    Hochflexibel heisst bei mir nicht einen Algorithmus zu haben, dessen Ablauf weitestgehend von länger-existierendem State beeinflusst wird.

    Du blendest hier das Große-Ganze aus.
    Weiter unten werde ich das noch näher beschreiben.

    Also gibst du mir recht, dass jegliche Änderung/Erweiterung im OO-Kontext eines aufwädigen Refactoringprozesses bedarf?


    So jetzt wird die ganze Sache spannend.

    if-else sind Kontrollstrukturen, mit denen ich im wesentlichen meinen Algorithmus aufspanne.
    Du sagst, man sollte derartiges nicht verwenden?
    Wo und wie bitteschön konfigurierst du dann deine Objekte.

    Wo und wie bitteschön bestimmst du dann später ganz konkret welcher deiner polymorphen Objekte an eine Variable gebunden werden sollen, auf dessen Grundlage du ja dann später weiterarbeiten wirst?

    Du musst hier ganz genauso if-else verwenden.
    if(........)
    {
    foo=so und so;
    }
    else
    {
    foo=ein anderes so und so;
    }

    später rufst du dann foo.doAction() auf!

    so ich glaube ich muss einen neuen Begriff einführen:
    Es gibt Dinge die zur Compilezeit entschieden werden.
    Es gibt Dinge die zur Laufzeit entschieden werden.

    Und genau zweiteres sollte ab jetzt genauer differenziert werden.
    Es gibt Dinge, die sehr früh zur Laufzeit entschieden werden (Objektkonfiguration, DI, etc pp)
    Es gibt Dinge, die unmittelbar vor der eigentlichen Ausführung entschieden werden (ein temporäres Action-Objekt, dass dann kurz ausgeführt wird und anschließend zerstört wird, nur dann sinnvoll, wenn die Ausführlocation wo anders ist..... dafür gibts aber auch Lambdas und Ähnliches)

    Es gibt Dinge die zur Laufzeit entschieden werden (meine flexible Programmierung!)

    Alle drei Arten wie Code zur Laufzeit ausgeführt wird, unterliegen der Tatsache, dass man hier if-else verwenden muss.

    Die letzt genannte Option ist aber die flexibelste.
    Warum? Siehe folgendes:

    Ein Algorithmus der konfigurierbar ist, aber sowieso bei jedem Request umkonfiguriert wird, ist erstmal nicht unflexibel. Aber die Tatsache dass er von vornherein konfiguriert worden ist, ist in dem Fall quatsch, weil ich ihn ja sowieso nach belieben "neu" konfiguriere und zwar jedesmal wenn er dran/bei jedem Request.

    Und somit ist das so im Umkehrschluss nicht vorgesehen, dass ich ihn ständig umkonfiguriere!
    => Da das nicht vorgesehen ist => ist das ganze unflexibler!



    Wenn du das schon so schreibst:
    Warum dann nicht gleich access_Room als Methode in die Klasse Raum bauen?

    Ganz einfach weil access_room viel komplexer aufgebaut ist, und vllt. nicht nur die Raum-Daten benötigt sondern von vielen anderen Objekten auch noch Daten. => ich baue eine Prozedur, die den Raum bekommt und viele andere Objekte auch noch, um dann zu entscheiden, ob ein Zugriff gewährt wird


    Zu deiner Frage mit der ID und Instanz:
    Vllt. existiert der Raum ja gar nicht auf meinem HEAP, sondern in der Datenbank, oder er ist nur via eines REST-Calls oder Whatever zu erreichen. Jetzt kommt dann vermutlich von deiner Seite wieder die Argumentation, dass in dem Fall der Raum ein Proxy ist. Finde ich aber nicht so hübsch, eine ID ist viel schlanker als ne Instanz proxy_Raum im Speicher zu halten. Vllt. existiert der Informationsträger, der die ID zum Raum besitzt gerade gar nicht selbst im Speicher. Das heisst ich müsste in dem Fall erstmal nen Rießen Objektgraphen in den Speicher setzen, um dann access_room auszuführen. Direkte Datenbankoptimierungen sind so dann nicht mehr vorgesehen.


    Weil ich das so bestimmt habe, dass der Motor keinen PIN braucht?
    Kreativität ist in der OO scheinbar nicht gern gesehen^^ => Unflexibiltät^^
    Die 7 ist auch von mir, ist halt in dem Beispiel jetzt einfach mal hart codiert, muss später natürlich nicht so sein.
    Wie würde eine Objektinstanz da so einfach reinkommen?, wo ich doch nichtmal alle Türen im Speicher vorhalten möchte?

    Also ich hätte da wirklich mal Lust mit dir zu skypen. Die öffentliche Diskussion hier und mal ne private mit Dir schließen sich ja nicht gegenseitig aus.

    Ich habe nie gesagt, dass ich allgemein etwas gegen Polymorphie habe.
    Funktionspointer/Lambdas und so setze ich sehr gerne ein.
    Aber das macht noch lange kein prozedurales Programm zu einem Objektorientierten.

    Richtig die Daten liegen am besten in einer Datenbank.
    Die Prozeduren, die dann mit den Daten arbeiten ,müssen die Räume ja nicht unterschiedlich behandeln.
    Sollte ich aber eine komplexe Ablaufsteuerung benötigen, dann wäre das wesentlich einfacher in prozedural organisierten Welt als in einer objektorientierten Welt umsetzbar.

    Ich glaube das habe ich ganz am Anfang dieses Beitrags hier bereits beantwortet^^



    @Meniskusschaden
    zu deinem Code:

    Das ist ungefähr das pentadent hierzu:

    Du hast nen User: Einer davon ist normaler User, der andere Admin
    und je nach Usertype verhalten sich diverse Funktionen anders.

    Statt irgendwo dann if(usertype=="admin"){} zu schreiben, hast du einen polymorphen Code, ABER in OO Manier.
    Das beantwortet auch schon deine Frage, wie ich es prozedural programmieren könnte.

    Dein Code in OO Manier hat aber ein paar Probleme (damit meine ich nicht unlösbar, aber einfach nur ne hässliche Transformation und viel Overhead, um folgende Problemstellung in OO auszudrücken)


    Du hast nen Algorithmus, erstmal sehr generisch! Und dann kommt spezifischer Code, den ich aber im Entwicklungsprozess schön mit dem generischen verzahnen möchte, sodass das TemplatePattern hier nicht so einfach funktioniert. Zumal das eh schon wieder unnötiger Overhead wäre.

    ....
    ....
    .... // hier sind kontextdaten, die gleich in folgendem block mitverwendet werden sollen
    if(usertype=="admin")
    {
    //also hier
    }
    ....
    ....
    ....

    //so und eventuell hast du dann auch noch das hier:

    if(usertype=="admin")
    {
    ...
    ...
    if(usertype2=="IRGNDWAS")
    {
    ....
    }
    ....
    }
    ....
    ....
    ....


    Jetzt bin ich gespannt, wie du diesen verchachtelten Algorithmus in einen polymorphen OO-Aussehenden transformieren möchtest.


    Zudem, was ich an solchen Beispielen immer hasse, an einem das du mir gegeben hast, und was auch im Designpattern-Buch so verwendet wird:

    System.out.println IST global!
    Und hat in einem konsistentem OO-Beispiel eigentlich nichts verloren.

    Die Frage, die sich zudem ergibt:
    Du hast da jetzt sehr einfache Methodenaufrufe, wie move()

    Gehen wir mal davon aus, du hättest da nen wesentlich komplexeren Algorithmus
    moveKomplex(....), der sich dann nicht mehr einem dieser Typen zuordnen lässt.
    Dazu kommt dass dieses moveKomplex je nach Parameterwerte nicht nur ein Tier bewegen lässt und eine Transaktionssicherheit möchte ich auch noch haben. Falls es irgendwo Probleme gibt -> Rollback!

    Also ein Algorithmus für den man klassischerweise eine Serviceklasse benötigt.
    Wie würdest du es dann machen: Wie Polymorphie und OO sowie die Tatsache, dass du eine Serviceklasse benutzt, in Einklang bringen?


    Soweit mal wieder



    lg knotenpunkt
     
  10. AndiE
    AndiE Aktives Mitglied
    Was heißt den "flexibel"? Wir haben bei oben genanntem Beispiel eine Anzahl Räume und eine Anzahl Personen. Offensichtlich kann ich die Personen in Gruppen zusammenfassen. Somit hat z.B. für den Raum 128 der Professor A alle Rechte, die Studenten der Klasse B das Recht zum Türöffnen und der Hausmeister H das Recht, die E-Anlage zu bedienen. Um das einzustellen, benötige ich nur das Programm, das im Speicher verschiedene Tupel hinterlegt. Die Änderung der Zugriffe wird nur durch Änderung der Tupel eingerichtet.
    Damit ist das Programm für mich hochflexibel, da sein Verhalten einerseits innerhalb des Anwendungsfalles schnell geändert werden kann und auch problemlos auf einen anderen Anwendungsfall( anderes Gebäude, andere Struktur der Belegschaft) geändert werden kann.
    Offensichtlich benötige ich nur eine Struktur aus n Sensoren und m Aktoren und k Identifizierungsobjekten( Zutrittskarten, RFID usw.).

    Ist das nicht flexibel genug? Man kann auch mit einem Schraubendreher, keine Wand anmalen.
     
  11. Wenn du Java lernen möchtest, empfehlen wir dir diesen Kurs hier
Passende Stellenanzeigen aus deiner Region:





Die Seite wird geladen...

OO ist gescheitert - Ähnliche Themen

Modellierung Chat-Server (von OO ist gescheitert)
Modellierung Chat-Server (von OO ist gescheitert) im Forum Softwareentwicklung
Weihnachtsbaum implementieren gescheitert.
Weihnachtsbaum implementieren gescheitert. im Forum Java Basics - Anfänger-Themen
Tannenbaum implementieren gescheitert
Tannenbaum implementieren gescheitert im Forum Java Basics - Anfänger-Themen
Code auf Klasse verlegen - Mission gescheitert
Code auf Klasse verlegen - Mission gescheitert im Forum Java Basics - Anfänger-Themen
Gescheiterte Projekte bzw. Konsequenzen
Gescheiterte Projekte bzw. Konsequenzen im Forum Plauderecke
Thema: OO ist gescheitert