Please enable JavaScript.

Coggle requires JavaScript to display documents.

Java 15 - Coggle Diagram

- - - - enum Planet { MERCURY (3.303e+23, 2.4397e6), VENUS (4.869e+24, 6.0518e6), EARTH (5.976e+24, 6.37814e6), ... }
      - sealed interface Celestial { record Planet(String name, double mass, double radius) record Star(String name, double mass, double temperature) implements Celestial {} record Comet(String name, double period, LocalDateTime lastSeen) implements Celestial {} }
  - - - sealed interface Shape { record Circle(Point center, int radius) implements Shape { } record Rectangle(Point lowerLeft, Point upperRight) implements Shape { } }
      - Wait, isn't this violating encapsulation?
        
        Historically, object-oriented modeling has encouraged us to hide the set of implementations of an abstract type. We have been discouraged from asking "what are the possible subtypes of Shape", and similarly told that downcasting to a specific implementation class is a "code smell". So why are we suddenly adding language features that seemingly go against these long-standing principles? (We could also ask the same question about records: isn't it violating encapsulation to mandate a specific relationship between a classes representation and its API?)
        
        The answer is, of course, "it depends." When modeling an abstract service, it is a positive benefit that clients interact only with the service through an abstract type, as this reduces coupling and maximizes flexibility to evolve the system. However, when modeling a specific domain where the characteristics of that domain are already well known, encapsulation may have less to offer us. As we saw with records, when modeling something as prosaic as an XY point or an RGB color, using the full generality of objects to model data requires both a lot of low-value work and worse, can often obfuscate what is actually going on. In cases like this, encapsulation has costs not justified by its benefit; modeling data as data is simpler and more direct.
        
        This doesn't mean that encapsulation is a mistake; it merely means that sometimes the balance of costs and benefits are out of line, and we can use judgment to determine when it helps and when it gets in the way. When choosing whether to expose or hide the implementation, we have to be clear about what the benefits and costs of encapsulation are. Is it buying us flexibility for evolving the implementation, or is it merely an information-destroying barrier in the way of something that is already obvious to the other side? Often, the benefits of encapsulation are substantial, but in cases of simple hierarchies that model well-understood domains, the overhead of declaring bulletproof abstractions can sometimes exceed the benefit.
        
        When a type like Shape commits not only to its interface but to the classes that implement it, we can feel better about asking "are you a circle" and casting to Circle, since Shape specifically named Circle as one of its known subtypes. Just as records are a more transparent kind of class, sums are a more transparent kind of polymorphism. This is why sums and products are so frequently seen together; they both represent a similar sort of tradeoff between transparency and abstraction, so where one makes sense, the other is likely to as well.
  - - - AsyncResult<V> r = future.get(); switch (r) { case Success(var result): ... case Failure(Throwable cause): ... case Timeout(), Interrupted(): ... }
      - sealed interface AsyncReturn<V> { record Success<V>(V result) implements AsyncReturn<V> { } record Failure<V>(Throwable cause) implements AsyncReturn<V> { } record Timeout<V>() implements AsyncReturn<V> { } record Interrupted<V>() implements AsyncReturn<V> { } } ... interface Future<V> { AsyncReturn<V> get(); }
    - - interface Future<V> { ... V get(long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException; }
      - try { V v = future.get(); // handle normal completion } catch (TimeoutException e) { // handle timeout } catch (InterruptedException e) { // handle cancelation } catch (ExecutionException e) { Throwable cause = e.getCause(); // handle task failure }