干净的建筑。方案的理解

Question

你能帮我理解接下来的事情吗？所以，我读了 R.Martin 的 Clean Architecture 并且有很多方案。

图片1：

我的实施：

Billing.java

public class Billing {

    public Billing(){

        //creating of licenses

        License personalLicense = new PersonalLicense();

        License businessLicense = new BusinessLicense();

        //method using

        personalLicense.calcFee();

        businessLicense.calcFee();

    }

}

License.java

public interface License {

    public void calcFee();

}

PersonalLicense.java

public class PersonalLicense implements License {

    public PersonalLicense(){

        //constructor implementation here

    }

    @Override

    public void calcFee(){

        //method implementation here

    }

}

BusinessLicense.java

public class BusinessLicense implements License {

    //private ? users - Unknown type just for example

    @Override

    public BusinessLicense(){

        //constructor implementation here

    }

    public void calcFee(){

        //method implementation here

    }

}

图二：

我的实施：

U1Ops.java

public interface U1Ops{

    public void op1();

}

U2Ops.java

public interface U2Ops{

    public void op2();

}

U3Ops.java

public interface U3Ops{

    public void op3();

}

OPS.java

public class OPS implements U1Ops, U2Ops, U3Ops{

    public OPS(){ ... }

    @Override

    public void op1() { ... }

    @Override

    public void op2() { ... }

    @Override

    public void op3() { ... }

}

User1.java

public class User1 {

    public User1(){

        OPS u1Ops = new U1Ops();

        u1Ops.op1();

    }

}

User2.java

public class User2 {

    public User2(){

        OPS u2Ops = new U2Ops();

        u2Ops.op2();

    }

}

User3.java

public class User3 {

    public User3(){

        OPS u3Ops = new U3Ops();

        u3Ops.op3();

    }

}

图三：

我的实施：

Permissions.java

public class Permissions{

    public Permissions() { ... }

    public classMethod() { ... }

}

User1.java

public class User1 {

    public User1(){

        Permissions p = new Permissions();

        p.classMethod();

    }

}

Answer 1

图片1：License, PersonalLicense,BusinessLicense可以，Billing必须是这样的：public class Billing {    private Lisense license;    public Billing(License license){        this.license = license;    }    public void pay(){       // some code       this.license.calcFee();       // some code    }    public void setLicense(License license){        this.license = license;    }}它看起来像Strategy pattern，它允许您定义一系列算法 ( License)，将它们中的每一个放入一个单独的类 ( PersonalLicense, BusinessLicense)，并使它们的对象可以互换。主要特点是该类Billing只知道它有一些许可证对象，calcFee而不知道具体的实现。稍后，为了支持新的许可证类型，您将创建新的实现License并且不会修改Billing.图二：User1, User2, User3, 必须是类似的东西，具有相应的 U*Ops：public class User1 {    private U1Ops u1Ops;    public User1(U1Ops u1Ops){        this.u1Ops = u1Ops;    }}// usage of classesOPS ops = new OPS();User1 user1 = new User1(ops);User2 user2 = new User2(ops);看起来像是来自SOLID的接口隔离原则示例，它指出不应强制客户端（User1、、）依赖于它不使用（只需要）的User2方法。User3User1op1()图三：与前面的示例一样，关联必须通过实例字段来实现User。这些图演示了依赖倒置原则（上部 - 不好的做法，下划线 - 好的做法）。根据它，User必须只知道一些抽象Permissions接口而不是具体实现，Permissions类只知道Permissions它实现的接口。使用这个原则，Entities模块创建自己的抽象级别（API） -Permissions接口并Authorizer使用它。与之相关的术语是依赖注入，通常用于 java 框架（例如Spring Framework ）以实现模块之间的低耦合