Builders for subclasses cannot initialize inherited private attributes

[schmalzing]

Issue description

The class-diagram generator creates builders for all classes when ${decConfig.withBuilders().defaultApply()} is configured. For subclasses, the generated builder also initializes attributes inherited from the superclass.

However, when an inherited attribute is declared private, the generated subclass builder accesses it directly. Since private Java fields cannot be accessed from a subclass, the generated Java sources fail compilation.

Reproduction

Example CD:

classdiagram CD {
  public class A {
    private String name;
  }

  public class B extends A { }
}

Generate the Java code with:

${decConfig.withBuilders().defaultApply()}

Actual behavior

The generator creates BBuilder and emits code equivalent to:

var v = new B();
v.name = this.name;

This produces a Java compiler error:

ERROR in ...\test\CD\BBuilder.java (at line 104)
v.name = this.name;
  ^^^^
The field A.name is not visible

The generated BBuilder tries to directly initialize name, although the attribute is declared as private in superclass A.

Expected behavior

The generated builder for a subclass must not directly access private attributes declared in a superclass.

Possible valid generator behavior would be one of:

• Initialize inherited attributes through an accessible constructor, setter, or other method declared by the superclass.
• Delegate initialization of inherited attributes to the superclass builder.
• Exclude private inherited attributes from the subclass builder.

Impact

Any CD containing a subclass whose superclass declares private attributes can produce Java code that does not compile when builders are enabled. This prevents the use of encapsulated attributes together with inheritance in generated POJO models.

[schmalzing]

Potential Solution 1: Builder inheritance

Generated java code:

class ABuilder {
  // [...]

  A build() {
    if (!isValid()) {
      // [...]
    }
    return doBuild(new A());
  }

  A doBuild(A a) {
    a.name = this.name;
    return a;
  }
}

class BBuilder extends ABuilder {
  // [...]

  B build() {
    if (!isValid()) {
      // [...]
    }
    return doBuild(new B());
  }

  B doBuild(B b) {
    super.doBuild(b);
    return b;
  }
}

Implications

For this to work, the generator for BBuilder needs to assume that an ABuilder with the corresponding doBuild method exists. However, the <<builder>> and <<noBuilder>> stereotypes allow the generator to create builders only for specific classes.

We should enforce a context condition ensuring that, if a class has the <<builder>> stereotype, all its superclasses have it as well.

[schmalzing]

Potential Solution 2: Constructors

Generated java code:

class A {
  A(String name) {
    this.name = name;
  }

  String name;
}

class B extends A {
  B(String name) {
    super(name);
  }
}

Implications

A constructor in Java has a fixed parameter order. This order needs to be derived from somewhere (e.g., from the order as the attributes appear in the class diagram, from their alphabetical order, or otherwise).

However, whichever order we choose, changes to the class diagram may affect the constructor in unforeseen ways. The problem is somewhat mitigated because the constructor is mostly accessed from generated code (it is not visible in the model). However, any handwritten code extension that relies on the constructor may be affected by changes that appear to be purely editorial in nature, such as reordering attributes in the class diagram.

[schmalzing]

Decision: accessor methods and or inheritance. If the <<builder>> stereotype is applied to a subclass B, then one of the following must hold:
a) SuperClass A has a Builder (i.e., the <<builder>> stereotype)
b) SuerClass A has only public attributes (or public setters)