你能幫我理解接下來的事情嗎？所以，我讀了 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(); }}
1 回答
千萬里不及你
TA貢獻1784條經驗 獲得超9個贊
圖片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?）以實現模塊之間的低耦合
添加回答
舉報
0/150
提交
取消