On dependency injection and inversion of control

Posted by mckintosh18 on Fri, 10 Apr 2020 16:30:22 +0200

Attribute level granularity

public class Tire {
    private double size;
    public Tire(double size){
        this.size = size;
    }
}
public class Bottom {
    private Tire tire;
    public Bottom(int size){
        // Create dependent object components
        this.tire = new Tire(size);
    }
}
public class Framework {
    private Bottom bottom;
    public Framework(int size){
        // Create dependent object components
        this.bottom = new Bottom(size);
    }
}
public class Luggage {
    private Framework framework;
    public Luggage(int size){
        // Create dependent object components
        this.framework = new Framework(size);
    }
    public void move(){
        // Logical flow
    }
}
public class Main {
    public static void main(String[] args) {
        // Attribute level granularity, dependent components will be created one by one internally
        Luggage luggage = new Luggage(20);
        luggage.move();
        /**
         * This granularity is not maintainable
         */
    }
}

In this way, when the top-level component is created, the dependent components will be created in turn, and the parameters will be passed from the top level to the dependent components. In this process, if the parameters of the dependency change, then all the top-level components used to this component need to change. This dependency tight coupling is difficult to maintain

And the granularity of dependence is too fine, so it should not be accurate to the attribute value level. Changing to the object level can greatly reduce the coupling

Object level granularity

public class Tire {
    private double size;
    public Tire(double size){
        this.size = size;
    }
}
public class Bottom {
    private Tire tire;
    public Bottom(Tire tire){
        this.tire = tire;
    }
}
public class Framework {
    private Bottom bottom;
    public Framework(Bottom bottom){
        this.bottom = bottom;
    }
}
public class Luggage {
    private Framework framework;
    public Luggage(Framework framework){
        this.framework = framework;
    }
    public void move(){
        // Logical flow
    }
}
public class Main {
    public static void main(String[] args) {
        /**
         * Object component granularity
         * Object component granularity benefits: when an object component changes, there is no need to modify the code that depends on the changed object component,
            This kind of change occurs in a more detailed level of internal operation, as long as the interface provided by the change component to the external remains unchanged
         * */

        // Object component
        Tire tire = new Tire(20);
        // Object component
        Bottom bottom = new Bottom(tire);
        // Object component
        Framework framework = new Framework(bottom);
        // Object component
        Luggage luggage = new Luggage(framework);
        luggage.move();
        /*
        * Under granularity control, a rule can be defined: the interaction between object components only transfers object components to ensure the consistency of dependency and constraint between object components, 
            Passing attribute granularity only affects its own changes
        * It can be seen from this that a new problem will arise after a certain decoupling is reduced, that is, a lot of lines of code are suddenly added when doing one thing, but these codes may also
            The domain semantics of the current execution flow is not the same as that of the current execution flow. The ultimate purpose of this execution flow can be encapsulated in a domain, so this function can be defined as a construct
            Builder, according to the current programming mode, factory mode and builder mode, all do this
        * */

        /**
         * Everyone has different ways of thinking. Even if they accept the same knowledge, they will break and regroup under my thinking. The knowledge absorbed in their own way of thinking is their own
         * In java, any function must be bound to a class. In my mind, "in java, any function must be attached to a class." the following are
            It's explained in my mind
         * 
         * What is domain: domain is a logical boundary
         * The boundary of a single function is the function domain, that is, the function level
         * Because all functions need to be attached under the class, which class boundary is the class domain
         * The above only explains two kinds of fields, code blocks, which are generally understood as class fields
         * 
         * In the design of the whole architecture, more class domains will be generated. At this time, a higher level of abstraction will be achieved, and a new class domain level will be abstracted on the class or above, such as a very
            Large module Abstract field, in java is package
         */
    }
}

Topics: Attribute Java Programming