1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Java 15: Sealed Classes - Code…

Seltsame Lösung

  1. Thema

Neues Thema Ansicht wechseln


  1. Seltsame Lösung

    Autor: sevenacids 18.09.20 - 16:07

    Vornweg: Ich habe in Java keinerlei Erfahrung. Aus Sicht eines C#-Entwicklers (und wir alle sind uns sicher einig, dass sich beide Sprachen sehr ähnlich sind) ist es eine seltsame Lösung, was vermutlich daran liegt, dass man sowas in C# auch ohne explizites Feature bewerkstelligen kann.

    Möchte ich in C# einen endlichen Satz von abgeleiteten Klassen haben, erstelle ich hier einfach eine (abstrakte) Basisklasse mit einem internal- statt public bzw. protected-Konstruktor. Dadurch bin ich der Einzige, der den Typ instanziieren und damit ableiten kann, mit einem "InternalsVisibleTo"-Attribut sogar über Modulgrenzen hinweg. Dazu braucht es dann keine Liste an Typeinschränkungen, die man bei Bedarf dann auch noch erweitern muss. Für Konsumenten stellt man dann eine öffentliche Factory-Methode bereit.

    Inwiefern das beim Pattern Matching über Typen sinnvoll sein soll, erschließt sich mir auch nicht. Wenn ich in C# ein "if (x is Dog dog) { dog.Bark(); }" schreibe, dann funktioniert das mit allen Typen, die ein "Dog" oder davon abgeleitet sind. Das macht doch gar keinen Unterschied, ob die abgeleiteten Typen beschränkt oder unbeschränkt sind, oder täusche ich mich da?



    1 mal bearbeitet, zuletzt am 18.09.20 16:09 durch sevenacids.

  2. Re: Seltsame Lösung

    Autor: Jonny Dee 18.09.20 - 17:47

    sevenacids schrieb:
    --------------------------------------------------------------------------------
    > Inwiefern das beim Pattern Matching über Typen sinnvoll sein soll,
    > erschließt sich mir auch nicht. Wenn ich in C# ein "if (x is Dog dog) {
    > dog.Bark(); }" schreibe, dann funktioniert das mit allen Typen, die ein
    > "Dog" oder davon abgeleitet sind. Das macht doch gar keinen Unterschied, ob
    > die abgeleiteten Typen beschränkt oder unbeschränkt sind, oder täusche ich
    > mich da?

    Der Vorteil wird erst bei einem "switch" mit Pattern Matching richtig ersichtlich. Der Compiler kann bei "sealed" Klassen erkennen, wie viele verschiedene Typen es gibt und kann damit eine Warnung (oder einen Fehler) ausgeben, wenn ein "switch" Statement nicht erschöpfend gegen alle Typen matcht.

  3. Re: Seltsame Lösung

    Autor: Trockenobst 19.09.20 - 04:48

    Jonny Dee schrieb:
    --------------------------------------------------------------------------------
    > Der Vorteil wird erst bei einem "switch" mit Pattern Matching richtig
    > ersichtlich.

    Diese Art der starren Compile Time Prüfung hatte ich nie gebraucht. Vor allem wenn die switch() cases dynamisch zur Laufzeit geprüft werden müssen, weil z.B. Module nach dem Start geladen werden. Die ganze Entwicklerwelt bewegt sich mit große Schritten weg von Monolithen und hin zu assoziativen Modulen und Komponentengruppen.

    Sealed Classes bringen nur in ganz wenigen Umgebungen etwas, wo der Code eine sehr rigide Sicht der Welt abbildet. Der Fall, dass der Chef reinkommt und fragt, warum beim Interface "Automarke" vor 10 Jahren Tesla nicht in der sealed liste war. Und schon musst du dich fragen, warum du so tief unten fachspezifische Details mit schleppst.

  4. Re: Seltsame Lösung

    Autor: supersux 19.09.20 - 08:01

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > Jonny Dee schrieb:
    > ---------------------------------------------------------------------------
    > Diese Art der starren Compile Time Prüfung hatte ich nie gebraucht. Vor
    > allem wenn die switch() cases dynamisch zur Laufzeit geprüft werden müssen,
    > weil z.B. Module nach dem Start geladen werden. Die ganze Entwicklerwelt
    > bewegt sich mit große Schritten weg von Monolithen und hin zu assoziativen
    > Modulen und Komponentengruppen.

    mmhhh...interessant wie unterschiedlich die Eindrücke dahingehend sein können. Für das Java-Ökosystem z.B. ist meiner, dass Dank Containerorchestrierungen & Co. als neue "Runtime" der Trend genau weg von dynamisch nachgeladenen Modulen u.ä. geht (und damit mehr oder weniger auch hin zur closed-world assumption in den Fachservices).

    > Sealed Classes bringen nur in ganz wenigen Umgebungen etwas, wo der Code
    > eine sehr rigide Sicht der Welt abbildet. Der Fall, dass der Chef reinkommt
    > und fragt, warum beim Interface "Automarke" vor 10 Jahren Tesla nicht in
    > der sealed liste war. Und schon musst du dich fragen, warum du so tief
    > unten fachspezifische Details mit schleppst.

    So wie ich es verstande habe, geht es bei den SealedClasses doch in dem größten Teil der UseCases für Otto-Normal-Entwickler ja genau darum, eben diese rigide Sicht der Welt (sprich: das Domainmodell) abzubilden.
    Wenn also der Chef reinkommt und verkündet, das ab sofort auch Tesla aufzunehmen ist, wird die sealed liste der Automarken erweitert und Entwickler & Compiler können sich dann über die Vollständigkeit der weiteren Implementierungsdetails unterhalten ;-)
    Quasi wie Enums - nur statt einem Objekt pro Typ, hier eben mit ganzen Klassenhierarchien. Also imho durchaus eine nette, zusätzliche Option.

  5. Re: Seltsame Lösung

    Autor: BLi8819 19.09.20 - 09:57

    > Inwiefern das beim Pattern Matching über Typen sinnvoll sein soll, erschließt sich mir auch nicht.
    Wenn neben Hund, Katze und Maus nun die Ratte dazu kommt, sagt dir der Compiler, an welchen Stellen du dein Pattern Matching erweitern musst.

  6. Re: Seltsame Lösung

    Autor: Lord Gamma 19.09.20 - 13:12

    supersux schrieb:
    --------------------------------------------------------------------------------
    > ...
    > So wie ich es verstande habe, geht es bei den SealedClasses doch in dem
    > größten Teil der UseCases für Otto-Normal-Entwickler ja genau darum, eben
    > diese rigide Sicht der Welt (sprich: das Domainmodell) abzubilden.
    > Wenn also der Chef reinkommt und verkündet, das ab sofort auch Tesla
    > aufzunehmen ist, wird die sealed liste der Automarken erweitert und
    > Entwickler & Compiler können sich dann über die Vollständigkeit der
    > weiteren Implementierungsdetails unterhalten ;-)
    > Quasi wie Enums - nur statt einem Objekt pro Typ, hier eben mit ganzen
    > Klassenhierarchien. Also imho durchaus eine nette, zusätzliche Option.

    Das ist eigentlich eine Verletzung des Open-Closed-Prinzips und man sollte sich darüber im Klaren sein. Es ist nicht immer schlimm, wenn man getesteten und abgenommenen Code öffnen muss, um eine Erweiterung zu implementieren; man sollte es halt im Auge behalten und "Sealed Classes" lassen den Compiler ein wenig dabei helfen, Fehler zu vermeiden, wenn man dagegen verstößt.

  7. Re: Seltsame Lösung

    Autor: Lord Gamma 19.09.20 - 13:17

    BLi8819 schrieb:
    --------------------------------------------------------------------------------
    > > Inwiefern das beim Pattern Matching über Typen sinnvoll sein soll,
    > erschließt sich mir auch nicht.
    > Wenn neben Hund, Katze und Maus nun die Ratte dazu kommt, sagt dir der
    > Compiler, an welchen Stellen du dein Pattern Matching erweitern musst.

    Die Frage ist eher, ob man verhindern muss, dass bspw. ein Esel dazu kommt. Wenn nicht, dann kann man ja einfach überall Interface-Methoden verwenden, ohne sich darum zu kümmern, welche Implementierung kommt.

  8. Re: Seltsame Lösung

    Autor: supersux 19.09.20 - 15:09

    Lord Gamma schrieb:
    --------------------------------------------------------------------------------
    > supersux schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ...
    > > So wie ich es verstande habe, geht es bei den SealedClasses doch in dem
    > > größten Teil der UseCases für Otto-Normal-Entwickler ja genau darum,
    > eben
    > > diese rigide Sicht der Welt (sprich: das Domainmodell) abzubilden.
    > > Wenn also der Chef reinkommt und verkündet, das ab sofort auch Tesla
    > > aufzunehmen ist, wird die sealed liste der Automarken erweitert und
    > > Entwickler & Compiler können sich dann über die Vollständigkeit der
    > > weiteren Implementierungsdetails unterhalten ;-)
    > > Quasi wie Enums - nur statt einem Objekt pro Typ, hier eben mit ganzen
    > > Klassenhierarchien. Also imho durchaus eine nette, zusätzliche Option.
    >
    > Das ist eigentlich eine Verletzung des Open-Closed-Prinzips und man sollte
    > sich darüber im Klaren sein. Es ist nicht immer schlimm, wenn man
    > getesteten und abgenommenen Code öffnen muss, um eine Erweiterung zu
    > implementieren; man sollte es halt im Auge behalten und "Sealed Classes"
    > lassen den Compiler ein wenig dabei helfen, Fehler zu vermeiden, wenn man
    > dagegen verstößt.

    In der Tat, gleiches gilt auch schon bei den Java-14 Records: wie so oft in der Programmierung immer ein TradeOff.

  9. Re: Seltsame Lösung

    Autor: BLi8819 19.09.20 - 18:37

    Beides zusammen ist korrekt.

    Bei Interfaces hast du
    a) keine Möglichkeit eine Implementierungen zu verhindern
    b) sagt dir der Compiler nicht, ob du bei ein Machting Pattern eine Implementierung vergessen hast zu berücksichtigen.
    c) Evtl. willst du bei Hund und Katze das gleiche machen. Dann bräuchtest du schon wieder Basisklassen etc. Aber das will man nicht unbedingt nur für eine paar Codestellen.

    Ob man das wirklich braucht sei mal dahin gestellt.

  10. Re: Seltsame Lösung

    Autor: Lord Gamma 19.09.20 - 19:45

    BLi8819 schrieb:
    --------------------------------------------------------------------------------
    > Beides zusammen ist korrekt.
    >
    > Bei Interfaces hast du
    > a) keine Möglichkeit eine Implementierungen zu verhindern

    Ja, das wird schwierig, wenn die Außenschnittstelle des Moduls, das Interface ist. Stattdessen kann die Schnittstelle den Wert eines Enumtyps verlangen.

    > b) sagt dir der Compiler nicht, ob du bei ein Machting Pattern eine
    > Implementierung vergessen hast zu berücksichtigen.

    Ja, stattdessen kann man einen Enumtyp nutzen und der Compiler hilft dann.

    > c) Evtl. willst du bei Hund und Katze das gleiche machen. Dann bräuchtest
    > du schon wieder Basisklassen etc. Aber das will man nicht unbedingt nur für
    > eine paar Codestellen.

    Man kann natürlich auch Delegation usw. benutzen, d. h. Sowohl in Hund als auch in Katze das gleiche Verhalten injecten.

    > Ob man das wirklich braucht sei mal dahin gestellt.

    Ja. Wenn man künftig beliebig neue Typen/Kategorien mit den gleichen Methoden hinzukommen lässt, kann man Interfaces verwenden und sich das "Pattern Matching" sparen. Und wenn künftig eher komplett neues Verhalten hinzukommen wird (und wenn man neue Kategorien nur kontrolliert hinzukommen lassen möchte), nimmt man lieber Enums oder Sealed Classes. Wenn man nur modulintern neues Verhalten hinzukommen lässt und keine Angst vor wilden Interface-Implementierungen zu haben braucht, nutzt man vielleicht auch lieber das Command-Pattern. Die Möglichkeiten sind vielfältig und wollen abgewägt werden.



    2 mal bearbeitet, zuletzt am 19.09.20 19:47 durch Lord Gamma.

  11. Re: Seltsame Lösung

    Autor: Das Osterschnabeltier 19.09.20 - 20:32

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > Jonny Dee schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Der Vorteil wird erst bei einem "switch" mit Pattern Matching richtig
    > > ersichtlich.
    >
    > Diese Art der starren Compile Time Prüfung hatte ich nie gebraucht. Vor
    > allem wenn die switch() cases dynamisch zur Laufzeit geprüft werden müssen,
    > weil z.B. Module nach dem Start geladen werden. Die ganze Entwicklerwelt
    > bewegt sich mit große Schritten weg von Monolithen und hin zu assoziativen
    > Modulen und Komponentengruppen.
    >
    > Sealed Classes bringen nur in ganz wenigen Umgebungen etwas, wo der Code
    > eine sehr rigide Sicht der Welt abbildet. Der Fall, dass der Chef reinkommt
    > und fragt, warum beim Interface "Automarke" vor 10 Jahren Tesla nicht in
    > der sealed liste war. Und schon musst du dich fragen, warum du so tief
    > unten fachspezifische Details mit schleppst.

    Siehe Artikel, der Vorteil liegt darin, dass Library entwickler ein zusätzliches Werkzeug haben, das bereits in der Vergangenheit praktisch gewesen

    ... nicht alles was hinkt ist ein Vergleich. Wenn bei einem sealed interface nachträglich eine Implementierung dazu kommt gibt es Warnings, die früh abgefangen werden. Wenn sich ein ein interface, das nicht sealed ist, ändert dann führt das im besten Fall zu einem Crash, im schlechtesten Fall zu einem Bug.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. W3L AG, Dortmund
  2. Versicherungskammer Bayern Versicherungsanstalt des öffentlichen Rechts, München
  3. rema.germany, Gescher
  4. KfW Bankengruppe, Frankfurt am Main (Home-Office möglich)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Samsung 860 EVO Basic SATA-SSD 1TB für 86,76€, Sandisk Ultra 3D SATA-SSD 2TB für 138...
  2. (u. a. Cooler Master MasterLiquid ML360R RGB-Wasserkühlung für 107,90€, Transcend 430S SATA-SSD...
  3. (u. a. Apple iPhone 11 Pro Max 256GB 6,5 Zoll Super Retina XDR OLED für 929,98€)
  4. (u. a. Seagate Expansion Portable USB-HDD 1TB für 39,99€, Crucial X8 USB-SSD für 82,99€, WD...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Elektrisches Carsharing: We Share bringt den ID.3 nach Berlin
Elektrisches Carsharing
We Share bringt den ID.3 nach Berlin

Während Share Now seine Elektroautos aus Berlin abgezogen hat, bringt We Share demnächst den ID.3 auf die Straße. Die Ladesituation bleibt angespannt.
Ein Bericht von Friedhelm Greis

  1. Verbraucherschützer Einige Elektroautos sind nicht zuverlässig genug
  2. Innovationsprämie Staatliche Förderung drückt Preise gebrauchter E-Autos
  3. Papamobil Vatikan will auf Elektroautos umstellen

Keyboardio Atreus im Test: Die Tastatur für platzbewusste Ergonomiker
Keyboardio Atreus im Test
Die Tastatur für platzbewusste Ergonomiker

Eine extreme Tastatur für besondere Geschmäcker: Die Atreus von Keyboardio ist äußerst gewöhnungsbedürftig, belohnt aber mit angenehmem Tippgefühl.
Ein Test von Tobias Költzsch

  1. HyperX x Ducky One 2 Mini im Test Kompakt, leuchtstark, limitiert
  2. Nemeio Tastatur mit E-Paper-Tasten ist finanziert
  3. Everest Max im Test Mehr kann man von einer Tastatur nicht wollen

Boothole: Kein Plan, keine Sicherheit
Boothole
Kein Plan, keine Sicherheit

Völlig vorhersehbare Fehler mit UEFI Secure Boot führen vermutlich noch auf Jahre zu Problemen. Vertrauen in die Technik weckt das nicht.
Ein IMHO von Sebastian Grüner