eneR: OOP: Warum Services nicht statisch?

Hallo,
ich bin gerade im zweiten Semester Informatik und lese gerade die "Entwurfsregeln für interaktive Softwaresysteme". Dort steht bei Services:
"•Im Gegensatz zu Materialien gibt es von jedem Service nur ein Exemplar [...].
• Services werden an zentraler Stelle erzeugt und verdrahtet, beispielsweise in einer StartUp-Klasse, und den Werkzeugen bei Bedarf als Konstruktorparameter übergeben."
Warum werden die Services dann nicht gleich als static deklariert? Dann würde man sich das unnötige Übergeben sparen, oder?
Ich frag das hier, da ich die Antwort schnell brauche.

Danke schonmal im Vorraus für alle Antworten!
René

  1. Auf den Link hab ich keinen Zugriff.
    Was sind Materialien und Werkzeuge? Was heißt verdrahtet?
    Ich bin nicht der Experte für Java, aber vielleicht würde auch für andere ein bisschen mehr Zusammenhang was bringen?

    1. Auf den Link hab ich keinen Zugriff.

      Klar, mein Fehler. Hier ein besserer :P

      Was sind Materialien und Werkzeuge? Was heißt verdrahtet?

      Die ersten beiden findest du ausfühlich erläutert in dem PDF. "Verdrahtet" soll in diesem Zusammenhang wohl mit Referenzen versehen bedeuten.

      Ich bin nicht der Experte für Java, aber vielleicht würde auch für andere ein bisschen mehr Zusammenhang was bringen?

      Worum es geht, sind Richtlinien dazu, wie man Sofware richtig aufteilt. So macht es Sinn um ein Problem zu lösen die Logig von der Darstellung zu trennen etc.

  2. Hallo,

    ich bin gerade im zweiten Semester Informatik und [...] frag das hier, da ich die Antwort schnell brauche.

    Schreibst wohl morgen eine Klausur und musst noch schnell alles lernen?

    • Services werden an zentraler Stelle erzeugt und verdrahtet, beispielsweise in einer StartUp-Klasse, und den Werkzeugen bei Bedarf als Konstruktorparameter übergeben."
    Warum werden die Services dann nicht gleich als static deklariert? Dann würde man sich das unnötige Übergeben sparen, oder?

    Also ich verstehe das so, dass es versch. Werkzeuge als Objektinstanzen geben kann, die mit einem Service arbeiten sollen. Damit sie diesen überhaupt kennenlernen, wird dem Konstuktor jeder neuen Werkzeuginstanz eine Referenz auf den einzigen Service (ein Singleton) mitgegeben. Der Service kann ruhig static deklariert sein. Das macht ihn aber noch nicht überall bekannt.

    Gruß, Don P

    1. Hallo,

      ich bin gerade im zweiten Semester Informatik und [...] frag das hier, da ich die Antwort schnell brauche.

      Schreibst wohl morgen eine Klausur und musst noch schnell alles lernen?

      Nein, ich versuche gerade dieses Konzept an einem Projekt umzusetzen und möchte damit schnell fertig werden :D

      • Services werden an zentraler Stelle erzeugt und verdrahtet, beispielsweise in einer StartUp-Klasse, und den Werkzeugen bei Bedarf als Konstruktorparameter übergeben."
      Warum werden die Services dann nicht gleich als static deklariert? Dann würde man sich das unnötige Übergeben sparen, oder?

      Also ich verstehe das so, dass es versch. Werkzeuge als Objektinstanzen geben kann, die mit einem Service arbeiten sollen. Damit sie diesen überhaupt kennenlernen, wird dem Konstuktor jeder neuen Werkzeuginstanz eine Referenz auf den einzigen Service (ein Singleton) mitgegeben. Der Service kann ruhig static deklariert sein. Das macht ihn aber noch nicht überall bekannt.

      Aber das erspart einem das blöde ge-referenzere:
      KlasseBla.machdas(); anstatt instanzvonKlasseBla.machDas();

      Gruß & Danke :D

      1. Moin!

        Also ich verstehe das so, dass es versch. Werkzeuge als Objektinstanzen geben kann, die mit einem Service arbeiten sollen. Damit sie diesen überhaupt kennenlernen, wird dem Konstuktor jeder neuen Werkzeuginstanz eine Referenz auf den einzigen Service (ein Singleton) mitgegeben. Der Service kann ruhig static deklariert sein. Das macht ihn aber noch nicht überall bekannt.

        Aber das erspart einem das blöde ge-referenzere:
        KlasseBla.machdas(); anstatt instanzvonKlasseBla.machDas();

        Wenn du statische Aufrufe in deinem Code verteilst, dann legst du dich damit ziemlich intensiv fest, welchen Code du an dieser Stelle verwenden willst.

        Nur mal so als Beispiel: Wenn deine statische Klasse DB-Aufrufe macht, bist du damit auf die konkrete Datenbank festgelegt und kannst das nur schwer wieder ändern, weil du dann an allen Stellen die statischen Aufrufe auf eine andere Klasse umbiegen musst.

        Wenn du eine Instanz in die andere Klasse gibst, dann hast du eine zentrale Stelle, die dir diese Klasse erzeugt, und bist an dieser zentralen Stelle flexibel, evtl. eine andere Klasse mit derselben Interface-Implementierung einzufügen.

        Statische Klassenaufrufe sind nicht der beste Programmierstil.

         - Sven Rautenberg

  3. Hallo eneR,

    "•Im Gegensatz zu Materialien gibt es von jedem Service nur ein Exemplar [...].

    Klingt nach Singleton-Pattern.

    Warum werden die Services dann nicht gleich als static deklariert? Dann würde man sich das unnötige Übergeben sparen, oder?

    Siehe Singleton-Pattern. Die dort verwendete Methode zum Zurückgeben der Instanz ist statisch.

    Das ist zumindest das, was ich den von dir gegebenen Informationen entnehmen kann. Ein etwas konkreterer Kontext wäre allerdings hilfreich.

    Grüße
    Richard

  4. Hallo,

    Warum werden die Services dann nicht gleich als static deklariert? Dann würde man sich das unnötige Übergeben sparen, oder?

    Wenn Du den Service als statisch deklarierst, kannst Du ihn ja nicht instanzieren.
    Dies wiederrum ist lästig, weil Du Services meistens irgendwie parametrisieren willst. Dann zwar nur EINMAL, aber leider ist dieses EINMAL oft zur Laufzeit, sprich, zur Implementierungszeit stehen die Parameter noch nicht fest.

    Denk Dir einen Service, der den Datenbank-Zugriff regelt. Dann möchtest Du ja evtl., dass dieser Service beim Initialisieren irgendwelche Werte mitbekommt (z.b. den Datenbank-Host o.ä.).

    Es kann auch sein, dass dieser Service widerrum einen anderen Service nutzt, aber erst zur Laufzeit feststeht, welchen er benutzen soll.

    Alles das spricht gegen eine Implementierung als "Static" Klasse.

    Was hingegen in manchen Fällen Sinn machen kann, ist, den Service als Singleton zu realisieren - dann kannst Du den Service trotzdem bei der ersten Instanzierung parametrisieren, stellst aber sicher, dass Du immer dieselbe Instanz des Services zurück bekommst (und nicht versehentlich zwei Services, die eigentlich das gleiche tun, in Deinem System herumsausen).

    Hoffe das hilft Dir weiter.

    Viele Grüße,
    Jörg