The order in which the builder is called

The order of the

Builder calls is briefly described in chapter 4th, but that is what is said before inheritance and the problem of polymorphism are introduced. The
Builder for the underlying class is definitely called in the builder of a derived class and is gradually linked up so that the builder used by each base class can be invoked. This is done because the builder has a special task: Check that the object is properly built. A derived class can access only its own members and cannot access members of the underlying class (these members usually have private properties). Only the builder of the underlying class knows the correct method and has the appropriate permissions when initializing its own elements. Therefore, all builders must be called, or the entire object may be built incorrectly. That's why the compiler is forced to make a builder call to each part of the derived class. In the builder body of a derived class, if we do not explicitly specify a call to a base class builder, it silently calls the default builder. If no default builder exists, the compiler will report an error (If a class does not have a builder, the compiler will automatically organize a default builder).
Let's take a look at an example that shows the effects of compositing, inheritance, and polymorphism in a build order:
 

: Sandwich.java
//order of constructor calls

class Meal {Meal (
  ) {System.out.println ("Meal ()");}

class Bread {
  Bread () {System.out.println ("Bread ()");}

Class Cheese {
  Cheese () {System.out.println ("Cheese ()");}

Class Lettuce {
  lettuce () {System.out.println ("lettuce ()");}

Class Lunch extends Meal {
  lunch () {System.out.println ("Lunch ()");}

Class Portablelunch extends Lunch {
  portablelunch () {
    System.out.println ("Portablelunch ()");
  }

class Sandwich extends Portablelunch {
  Bread b = new Bread ();
  Cheese C = new Cheese ();
  Lettuce L = new lettuce ();
  Sandwich () { 
    System.out.println ("Sandwich ()");
  }
  public static void Main (string[] args) {
    new Sandwich ();
  }
}///:~

This example creates a complex class outside of other classes, and each class has a builder that announces itself. The most important of these is sandwich, which reflects three levels of inheritance (in the case of the default inheritance from object, which is level four) and three member objects. After creating a sandwich object in main (), the output is as follows:

Meal ()
lunch ()
portablelunch ()
Bread
() Cheese () lettuce () Sandwich ()

This means that for a complex object, the calls of the builder follow the following order:
(1) invoke the base class builder. This step repeats itself, starting with the root of the hierarchy, then the next derivative, and so on. Until it reaches the deepest layer of the derivative class.
(2) Invoke the member initialization module in the order of Declaration.
(3) invokes the body of the derivation builder.

The order of the builder calls is very important. When inheriting, we know everything about the underlying class and have access to any public and protected members of the underlying class. This means that when we derive a class, we must be able to assume that all members of the underlying class are valid. With a standard approach, the build action is already in place, so members of all parts of the object are built. Within the builder, however, you must ensure that all the members you use are built. The only way to achieve this requirement is to invoke the underlying class builder first. Then, after entering the Derivative Class Builder, all the members that we have access to in the underlying class have been initialized. In addition, all member objects (that is, objects within the class by the compositing method) are defined within the class (for example, B,c and L in the previous example), so that all members within the builder are valid because we should initialize them as much as possible. Adhering to this rule will help us to determine that all the base class members and the member objects of the current object have been properly initialized. Unfortunately, however, this practice does not apply to all situations, which will be specified in the next section.