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

Und das sagt JEP 360 selbst

  1. Thema

Neues Thema Ansicht wechseln


  1. Und das sagt JEP 360 selbst

    Autor: rsaddey 19.09.20 - 12:33

    Java versucht nach-und-nach seine Schwächen im Bereich der Modularisierung zu heilen.

    Mich ärgert von Zeit zu Zeit maßlos, dass ich nichts anbieten kann, ohne dass es "raubkopierbar" ist. Damit meine ich, dass es sehr schwer ist, meine Consumer vom eigenen Re-Use abzuhalten. Meine Kollegen hassen mich, da ich oft erstmal alles als final deklariere. Nicht aus lizenzrechtlichen Gründen, sondern einfach, um selbst bessere Qualität mit weniger Aufwand zu erreichen. Package private Konstruktoren sind auch wirksam. Aber

    Meine schlimmste Erfahrung im Bereich unbeschränkten Re-Uses war Groovy (selige Grails Zeiten). Dabei wurde z.B. mit großer Kreativität auf private Felder und Methoden zugegriffen, deren Namen während der Laufzeit aus Zeichenketten zusammengesetzt wurden. Es geht doch. Ganz schnell!

    Im JEP 360 selbst steht zu sealed:

    For example, in a graphics library, the author of a class Shape may intend that only particular classes can extend Shape, since much of the library's work involves handling each kind of shape in the appropriate way. The author is interested in the clarity of code that handles known subclasses of Shape, and not interested in writing code to defend against unknown subclasses of Shape. Allowing arbitrary classes to extend Shape, and thus inherit its code for reuse, is not a goal in this case. Unfortunately, Java assumes that code reuse is always a goal: If Shape can be extended at all, then it can be extended by any number of classes. It would be helpful to relax this assumption so that an author can declare a class hierarchy that is not open for extension by arbitrary classes. Code reuse would still be possible within such a closed class hierarchy, but not beyond.

    Java developers are familiar with the idea of restricting the set of subclasses because it often crops up in API design. The language provides limited tools in this area: either make a class final, so it has zero subclasses, or make a class or its constructor package-private, so it can only have subclasses in the same package. An example of a package-private superclass appears in the JDK:

    package java.lang;

    abstract class AbstractStringBuilder {...}
    public final class StringBuffer extends AbstractStringBuilder {...}
    public final class StringBuilder extends AbstractStringBuilder {...}
    The package-private approach is useful when the goal is code reuse, such as the subclasses of AbstractStringBuilder sharing its code for append. However, the approach is useless when the goal is modeling alternatives, since user code cannot access the key abstraction -- the superclass -- in order to switch over it. It is not possible to allow users to access the superclass without also allowing them to extend it. (Even within a graphics library that declares Shape and its subclasses, it would be unfortunate if only one package could access Shape.)

    In summary, it should be possible for a superclass to be widely accessible (since it represents an important abstraction for users) but not widely extensible (since its subclasses should be restricted to those known to the author). Such a superclass should be able to express that it is co-developed with a given set of subclasses, both to document intent for the reader and to allow enforcement by the Java compiler. At the same time, the superclass should not unduly constrain its subclasses by, e.g., forcing them to be final or preventing them from defining their own state.

  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. STRABAG AG, Stuttgart
  2. über duerenhoff GmbH, Hamburg
  3. Stabilus GmbH, Koblenz, Langenfeld
  4. Stadt Lingen (Ems), Lingen (Ems)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de