Modellierung Chat-Server (von OO ist gescheitert)

Diskutiere Modellierung Chat-Server (von OO ist gescheitert) im Softwareentwicklung Forum; Ich würde mein Uni-System weiterspinnen. Der Professor Meier loggt sich ein. Dann erstellt er eine Sitzung " Zum Liebesleben der Heuschrecke" und...

  1. AndiE
    AndiE Aktives Mitglied
    Ich würde mein Uni-System weiterspinnen. Der Professor Meier loggt sich ein. Dann erstellt er eine Sitzung " Zum Liebesleben der Heuschrecke" und lädt dazu das 3. Semester ein. An einem anderen Computer loggt sich der Student Lehmann in das System ein und sieht, dass der Prof. Meier eine Sitzung erstellt hat und ihn dazu eingeladen hat. Den interessiert aber das Thema nicht, sondern er möchte lieber mit einigen Mitstudenten noch Nachhilfe in Schneckenkunde haben. Dies schreibt er dem Professor. Der erstellt nun innerhalb der Gruppe des 3. Semesters eine Gruppe "Schneckenkunde" und fügt die Betreffenden hinzu. Anschließend erstellt er einen Termin für eine Chatsitzung dazu.

    Frage: Wo sind hier die Räume? Welchen Vorteil hätten sie?

    Wäre die Unterteilung der Nutzer nicht sinnvoller?
     
  2. knotenpunkt
    knotenpunkt Neues Mitglied
    auch hier wirds morgen/heute weiter gehen^^

    lg knotenpunkt
     
  3. knotenpunkt
    knotenpunkt Neues Mitglied
    Hey,

    So dann gehts auch hier mal weiter:

    Nein! Es zeigt wie unflexibel OO ist! Wie bereits im anderen Faden aufgezeigt (Beitrag 89): Unflexibel != Unlösbar


    Das Switch-Case kann ich sehr wohl in ein Foreach(allCommandsList) ummünzen.
    Aber auch hier müsste ich neu programmierte Unterprozedur der allCommandsList hinzufügen.
    Zudem möchte ich es nicht bei dem vereinfachten switch-case belassen. Auch das kann ich komplexer gestalten. Hier wäre dann diese einfache Transformation auch nicht mehr möglich.
    Aber ich glaube du hast dir etwas ganz anderes darunter vorgestellt.
    Beschreibe doch mal deine Lösung, wo ich nur erweiternt einen Algorithmus schreiben muss und der dann sofort ohne Änderung an darüberliegender Strukur (in meinem Fall ja das switch-case) verfügbar ist.

    Erweiternt dann auch noch unter dem Gesichtspunkt, dass der Algorithmus tatsächlich nicht einfach nur über switch-case aufgerufen wird, sondern erst nach Abarbeitungen komplexer Voralgorithmen (ifs)

    Meiner Meinung nach geht das nicht. Klar, es bedarf hier einer Anpassung auch der darüberliegenden Struktur. Aber das ist ja vllt. auch gewollt?

    OO steht oft für Typerweiterung. Sprich ich decke eine Art horizontale Erweiterbarkeit mit OO ab.
    Ich hab eine Oberklasse Produkt und dann zwei Subklassen Milch und Apfel. Beide haben eine Funktion calculateOwnPrice(). Hier kann ich wirklich ganz einfach eine weitere Produkklasse hinzufügen. Bspw. Banane.
    Die Funktion calculateOwnPrice() bei der Banane ist auch sehr schnell geaddet. Die darüberliegende Struktur muss ich in dem Fall tatsächlich nicht anfassen.

    Aber es gibt eben auch die vertikale Erweiterbarkeit:
    Für das gibt es in der OO lustigerweise das VisitorPattern.

    Aber OO bekommt die vertikale und horzontale Erweiterbarkeit nicht unter einen Hut.
    Und für mich ist die Vertikale viel wertvoller, vor allem bekomme ich bei einer gut vertikal erweiterbaren Software auch eine direkte Flexibilität geschenkt.

    Gut jetzt bin ich etwas vom Thema abgeschweift!
    Back to the topic:


    Hier im Forum gehts mir jetzt tatsächlich um die Umsetzung. Ich möchte ja wissen wie es umgesetzt wird.
    Wie du es umsetzen würdest!^^


    Ok wie würdest ne Datenbankklasse schreiben und ne Loggerklasse.
    Sollte ein Query failen, dann gibts ne Request an die Loggerklasse, diese wiederrum verwendet dann wieder die Datenbankklase um die Fehlermeldung zu persistieren. Klar für den Fall, dass die Loggerklasse selbst gerade irgend eine Datenbankfunktionalität verwenden möchte, die aufgrund eines Datenbankdowns failed, muss hier eine Ausnahmeregelung geschaffen werden.

    Anderes Beispiel: Bibliothek und Bücher:

    Die Direktion Biblothek Richtung Bücher ist ja offensichtlich.
    Aber wenn ich jetzt vom Buch aus Richtung Bibliothek wissen möchte, welches Buch dessen Nachbar ist, oder in welcher Bibliothek es selbst sich befindet, dann habe ich hier ja auch eine zirkuläre Abhängigkeit.


    Wie würdest du meine beiden oben genannte Fallbeispiele ohne zirkuläre Abhängigkeiten umsetzen?


    Ja aber wir wollen es hier doch jetzt mal konkret machen.


    Naja du wolltest doch Anforderungen: Das ist eben eine^^
    Vllt. verhält sich tatsächlich nicht jeder Raum anders, aber es gibt vllt. Ausnahmen, vllt. auch nur kleine Detailunterschiede, oder aber doch ganz Hart, alles ist überall anders^^
    Diese Anforderungen interessieren mich insbesondere unter dem Gesichtspunkt, wie du sie jeweils technisch OO umsetzen würdest.



    kommt jetzt natürlich drauf an, wie man eine if-kaskade definiert:

    procedure1:
    if(bla_blub)
    {
    procedure2();
    }
    else
    {
    procedure3();
    }

    procedure2()
    {
    if(...)
    {
    procedure4()
    }
    }


    Ist das für dich eine if-kaskade?
    Und wie sieht das hier OO anders aus?


    Siehe Begründung weiter oben: Das Switch-Case kann ich ..............

    Und ja ich muss neu kompilieren, aber wenn das mein einziges Problem ist, warum nicht?
    Um die Neu-Kompilieren-Problematik mal etwas zu entkräften, was in deiner Argumentation ja doch viel Platz einnimmt.


    Doch man bekommt ungefähr eine Idee davon, wo nacher der Code steht. (zu Gleiches bist du üb........)

    Diese Idee hab ich aber nicht in der OO-Welt. Von daher frage ich ja, wie du es machen würdest
    Ja man sieht viel (Daten)-Struktur, wie auch in den ganzen Diagrammen, die ich oben aufrufen kann.
    Aber wo nacher der Code im Konkreten stehen wird, das kann ich da nicht herauslesen.


    Die Anforderungen habe ich doch bereits in meinem Eingangsbeitrag erklärt.

    Ein Raumtyp gibt schonmal ne gewisse Default-Raumkonfiguration vor.
    Diese können aber zur Compilezeit als auch zur Laufzeit angepasst werden.


    Zu den Befehlen habe ich doch auch bereits umfangreiche Beispiele gegeben, siehe Eingangsbeitrag.
    Und vor allem weil es viele Befehle gibt, die Raumübergreifend, Unterraumübergreifend, Global, oder von sonst wo her aufrufbar sind, ist es schwierig, diese an eine bestimmte Stelle zu modellieren.
    Aber gut, du bist ja der OO Spezialist. Ich bin auf deinen Ansatz gespannt^^


    Zu der Frage ob jeder Raum Unterräume haben darf, kann ich nur sagen:
    Was für eine Frage^^
    Du weißt doch, ich will alles so flexibel wie möglich haben: also JA^^
    Automatisch hat vllt. nicht gleich jeder Raum je nach Raumtyp und Konfiguration direkt die Möglichkeit Unterräume zu spawnen. Aber spätestens wenn ich als Admin einen entsprechenden Befehl ausführe, kann ich jedem Raum einen Unterraum verpassen - Zur Laufzeit!


    Soweit mal hier....


    lg knotenpunkt
     
  4. Meniskusschaden
    Meniskusschaden Bekanntes Mitglied
    Leider wieder zu unspezifisch für eine konkrete Antwort. Was ist allCommandsList in Bezug auf dein Codebeispiel?
    Polymorphie. Das switch-case entfällt.

    Wird er nicht. Das ist dein Denkfehler. Auf die Frage, wie man schlechtes Design zu gutem macht, ohne es zu ändern, gibt es keine Antwort. Wenn deine aufrufenden Algorithmen schlecht entworfen sind, wird es nicht besser, wenn sie Objekte verwenden. Ich habe ja in einem der beiden Threads schon mal geschrieben, dass man solche Designfehler mit PP oft länger verdecken kann. Vorteil oder Nachteil? Ich finde es besser, wenn man frühzeitig merkt, dass man seine Architektur versemmelt hat. Für mich also pro OOP.

    Was meinst du mit vertikaler und horizontaler Erweiterbarkeit und welches Problem hat die OO damit?
     
  5. mrBrown
    mrBrown Super-Moderator Mitarbeiter
    Unter Horizontal verstehst du das erweitern um neue Typen und unter Vertikal das Erweitern um neue Funktionen? (Die Begriffe hab ich in dem Kontext noch nie gehört...)


    Das Visitor-Pattern ist nur nötig, wenn die jeweilige Sprache kein Multi-Dispatch hat. Es gibt durchaus auch OO-Sprachen, die es haben, die dann kein Visitorpattern brauchen.
    Genauso kann man das Visitor-Pattern durch "if instanceOf"-Kaskaden ersetzen.

    Hauptanwendungsfall für's Visitorpattern: Der Laufzeittyp eines Objektes ist nicht bekannt, für unterschiedliche Typen müssen aber unterschiedliche Methoden aufgerufen werden.

    Wie bekommst du dass denn in PP einfacher hin? (zB mit C, so ganz ohne Laufzeit-Typen und Überladung...)

    Unsinn. Keine der Varianten ist deutlich flexibler als die andere (vielleicht das, was du unter "flexibel" verstehst, aber das würde auch niemand sonst so nennen).

    Können wir uns drauf einigen, entweder um die konkrete Umsetzung einzelner Teile zu reden oder um die Modellierung eines Gesamtsystems? Beides zu vermischen endet üblicherweise im Chaos.


    Alle statischen-Abhängigkeiten laufen nur in eine Richtung:
    Code (Text):

    ----------   ------------
    | Logger |-->| Appender | <--|
    ----------   ------------    |
        ^                        |
    ____|________________________|___
        |                        |
    --------------------      --------------------
    | Datenbank-Klasse | <--- | DatabaseAppender |
    --------------------      --------------------
     
    Die Anforderungen sind offensichtlich ein bisschen Unsinn.

    Für ein Buch rausfinden, aus welcher Bibliothek es kommt, kann man noch so halb gelten lassen. Umsetzen würde man das, indem Bücher einfach einen "Besitzer"(?) haben.
    Ein Buch fragen, wer sein Nachbar ist, ist aber schon Unsinn. Das ist etwas, was nicht vom Buch selber abhängt, warum sollte das Buch dann diese Information haben. Wenn unbedingt nötig, wäre das aber über den Umweg über den "Besitzer" möglich, Buch würde dann einfach an diesen delegieren.

    Code (Text):

    --------     ------------
    | Buch |---> | Besitzer |
    --------     ------------
       ^              ^
       |              |
    --------------    |
    | Bibliothek |-----
    --------------
     


    Nein. "alles mögliche und je nach Raum anders" ist keine Anforderung (dass du es für eine hälst, zeigt ziemlich deutlich, dass du dich noch nie mit Projektplanung etc beschäftigt hast).

    Nur mal hypothetisch, du als Kunde, ich als Entwickler:
    * wie soll ich als Entwickler auf dieser Basis den Aufwand schätzen?
    * wie willst du als Kunde prüfen, ob mein Preis gerechtfertigt ist?
    * wie soll ich als Entwickler jemals wissen, ob diese Anforderung erfüllt ist?

    In gleicher Detailiertheit:

    Code (Text):
    methodenAufruf()
    objekt.einMethodenAufruf()
    irgendwas.macheDas()
    Entweder du willst *konkrete Beispiele, dann bring selber konkrete Beispiele.
    Oder du willst über Modellierung reden, dann bring Anforderungen.
    Oder du willst Unsinn, dann ist das bisherige schon ganz passend ;)

    Du musst immer bestehenden Code ändern (bzw sogar nur eine Methode), um irgendeine Kleinigkeit zu ändern. Schon mal gesehen, wie gut es klappt, wenn mehrere Personen den gleichen Code ändern oder man immer an einer Codestelle arbeitet?
    Du kannst das ganze nicht modularisierten, weil du einen großen Blob hast.
    (Und zur Kompilezeit: Chromium z.B. braucht mehrere Stunden für ein frisches Kompilieren.)


    Ums noch mal zu wiederholen: ERST kommen Anforderungen, dann Modellierung, danach der Code.
    Niemanden interessiert vor dem festlegen der Anforderungen, wo nachher ein konkreter Code-Teil steht.

    Das sind wie schon gesagt keine Anforderungen, sondern irgendwelche Ideen, aus denen sich vielleicht irgendwann mal Anforderungen entwicklen.

    "irgendwas an eine bestimmte Stelle zu modellieren" ist auch absolut nicht nötig, hat auch niemand gefordert.

    Ansonsten, hier ist dein Produkt:

    Code (Java):

    public class Raum {
        String name = "DefaultName";
        List<Raum> unterräume;
        public void befehlAusführen(Consumer befehl) {
            befehl.consume();
        }

        //GETTER/SETTER
    }
     
    * Ein Raumtyp gibt schonmal ne gewisse Default-Raumkonfiguration vor. -> erfüllt, sie haben einen Default-Namen (nämlich "DefaultName")
    * Diese können aber zur Compilezeit als auch zur Laufzeit angepasst werden. -> Zur Kompilezeit kannst du neu kompilieren mit anderen Werten, zur Laufzeit kannst du einen Consumer übergeben, der den Raum verändern kann
    * Beliebige Befehle sind ausführbar, wobei die nirgends irgendwo eingeschränkt sind
    * Jeder Raum kann beliebige Unterräume haben

    Siehst du: Perfekt umgesetzt mit OOP.

    (Ja, das war Sarkasmus.)

    Was sind Raumtypen?
    Was ist deren Konfiguration?

    Einfach nur "Es gibt Raumtypen, die geben Konfigurationen vor" ist keine Anforderung.

    Was kann man anpassen?
    Ein "Alles" ist keine Anforderung.

    Nein, dort gibt es keine sinnvollen Anforderungen an Befehle. Einfach nur abstruse Beispiele Hinklatschen ist keine Anforderung.

    Du sollst auch nichts "an eine bestimmte Stelle modellieren" (was soll das heißen?), sondern einfach nur Anforderungen an Befehle stellen. Eine Anforderung, die du selber nicht aufschreiben kannst, ist keine Anforderung.

    Du wirst von niemandem, egal wofür der Spezialist ist, einen Ansatz bekommen, wenn du nicht in der Lage bist, auch nur minimalste Anforderungen vorzugeben. Auch nicht von einem PP-Spezialist.

    Das ist immerhin mal ein Ansatz einer konkreten Anforderung ;)

    Also: Ein Raum kann Unterräume haben, wenn es für diesen freigegeben ist.

    Ob er es darf, hängt von Typ und Konfiguration ab, wobei das von einem Admin überschrieben werden kann (= Konfiguration ändern?).
    Was ist ein Befehl in diesem Kontext? Ein Klick in der Oberfläche?
     
    Meniskusschaden gefällt das.
  6. Wenn du Java lernen möchtest, empfehlen wir dir dieses Online-Training hier
Passende Stellenanzeigen aus deiner Region:





Die Seite wird geladen...

Modellierung Chat-Server (von OO ist gescheitert) - Ähnliche Themen

Modellierung von Intervallen: Klasse Interval
Modellierung von Intervallen: Klasse Interval im Forum Allgemeine Java-Themen
[Modellierung] Verstoß gegen die NF?
[Modellierung] Verstoß gegen die NF? im Forum Datenbankprogrammierung
UML - Modellierung / Kompositum
UML - Modellierung / Kompositum im Forum Hausaufgaben
Modellierung (Use Case Diagramm)
Modellierung (Use Case Diagramm) im Forum Hausaufgaben
Objektorientierte Modellierung: Bank
Objektorientierte Modellierung: Bank im Forum Hausaufgaben
Thema: Modellierung Chat-Server (von OO ist gescheitert)