-
日常生活的策略查看全部
-
其实看到这里我有两个疑问： 1.如果以极限来思考，我们每个类都有一些属性，那么是否应该把一个简单的类，里面的行为（method）全部变成借口，然后使用组合方式来进行呢？这样是不是太过分了？哪里是一个“度”？怎么把握这个度？什么时候将method作为接口抽象出去，什么时候将其“理所应当”地作为类中的不变部分？ 2.在每次子类构造方法中，总是需要对父类的set相关方法的调用，这样，子类就“必须”知道父类中的相关内部细节才能决定子类自己的构造方法怎么去写，否则极易出现空指针，这是应该的吗？子类不应该知道父类的细节吧？何况，若是父类看不到其具体内部实现呢？不是自己写的而是历史遗留的代码呢？这很明显是不对的！查看全部
-
策略模式设计原则： 1.找出应用中需要变化的部分，把他们独立出来，不要和那些不需要变化的代码混在一起； 2.面向接口编程，而不是面向实现编程； 3.多用组合，少用继承 策略模式的实现： 1.通过分离变化得出策略接口Strategy 2.编写Strategy的实现类 3.客户端程序“有一个”Strategy 4.在客户程序中选择/组装正确的Strategy实现 策略模式的优点： 1.使用了组合，使架构更加灵活 2.富有弹性，可以较好的应对变化（开-闭原则） 3.更好的代码复用性（相对于继承） 4.消除了大量的条件语句 策略模式的缺点： 1.客户代码需要了解每个策略实现的细节 2.增加了对象的数目 策略模式的适用场景： 1.许多相关的类仅仅是行为差异 2.运行时选取不同的算法变体 3.通过条件语句在多个分支中选取一个查看全部
-
扩展功能类方法一（组合）： 将飞行行为抽象为接口，在父类中持有该接口，并由该接口代理飞行行为。 优点：有扩展性，有复用代码 缺点：查看全部
-
策略模式精髓: 1.Favor composition over inheritance复合（组合）优先于继承 2.组合定义：在类中增加一个私有域，引用另一个已有的类的实例，通过调用引用实例的方法从而获得新的功能，这种设计被称作组合（复合）（意思就是：得到其他类的对象，使用这个对象的方法。）查看全部
-
扩展功能类方法二（抽象方法）： 在父类中提供抽象方法，强迫子类实现自己的飞行行为 优点：具有扩展性，不会忘记覆写代码 缺点： 1.代码复用差 2.重复代码有bug,修改工作量太大 总结：有扩展性，没复用查看全部
-
扩展功能类方法一（继承）： 在父类中提供实现方法，子类通过继承获得父类中的飞行行为。 优点：已有应用可以快速添加飞行的能力 缺点： 1.单是继承的话：不具有灵活性，几乎没有扩展性，对未来变更支持差（复用，没扩展性） 2.加上覆写的话：需要通过在子类中覆写飞行方法以提供新的飞行行为，这很容易造成错误（粗心的程序员忘记了覆写），并且没能实现代码复用（用扩展性，没复用，还容易出错）查看全部
-
策略模式定义： 策略模式将可变的部分从程序中抽象分离成算法接口，在该接口下分别封装一系列算法实现并使它们可以相互替换，从而导致客户端程序独立于算法的改变查看全部
-
策略模式： 将可变的部分从程序中抽象分离成算法接口，在该接口下分别封装一系列算法实现。 并使他们可以相互替换， 从而导致客户端程序独立于算法的改变。查看全部
-
策略模式优点查看全部
-
策略模式适用场景查看全部
-
策略模式缺点查看全部
-
组合方法2查看全部
-
组合方法查看全部
-
组合或者复合查看全部
举报
0/150
提交
取消