干净的建筑。方案的理解

Question

你能帮我理解接下来的事情吗？所以，我读了 R.Martin 的 Clean Architecture 并且有很多方案。图片1：我的实施：Billing.javapublic class Billing {    public Billing(){        //creating of licenses        License personalLicense = new PersonalLicense();        License businessLicense = new BusinessLicense();        //method using        personalLicense.calcFee();        businessLicense.calcFee();    }}License.javapublic interface License {    public void calcFee();}PersonalLicense.javapublic class PersonalLicense implements License {    public PersonalLicense(){        //constructor implementation here    }    @Override    public void calcFee(){        //method implementation here    }}BusinessLicense.javapublic class BusinessLicense implements License {    //private ? users - Unknown type just for example    @Override    public BusinessLicense(){        //constructor implementation here    }    public void calcFee(){        //method implementation here    }}图二：我的实施：U1Ops.javapublic interface U1Ops{    public void op1();}U2Ops.javapublic interface U2Ops{    public void op2();}U3Ops.javapublic interface U3Ops{    public void op3();}OPS.javapublic class OPS implements U1Ops, U2Ops, U3Ops{    public OPS(){ ... }    @Override    public void op1() { ... }    @Override    public void op2() { ... }    @Override    public void op3() { ... }}User1.javapublic class User1 {    public User1(){        OPS u1Ops = new U1Ops();        u1Ops.op1();    }}User2.javapublic class User2 {    public User2(){        OPS u2Ops = new U2Ops();        u2Ops.op2();    }}User3.javapublic class User3 {    public User3(){        OPS u3Ops = new U3Ops();        u3Ops.op3();    }}图三：我的实施：Permissions.javapublic class Permissions{    public Permissions() { ... }    public classMethod() { ... }}User1.javapublic 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 classes

OPS 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 ）以实现模块之间的低耦合