return result;

　　}

　　classAccountType...

　　double overdraftCharge(Account account){

　　if (isPremium()){

　　double result = 10;

　　if (account.getDaysOverdrawn()> 7)

　　result += (account.getDaysOverdrawn()- 7)* 0.85;

　　return result;

　　}

　　else return account.getDaysOverdrawn()* 1.75;

　　}

　　分解类(Extract Class)

　　类的职责的划分不容易在初次设计时准确把握，所以在编码时重构是必要的。职责定位不清!——典型特征是拥有太多的成员变量;而在这里面重要的是职责要单一，属性和方法是否合适的类中。如果不是需要考虑分解或合并，扩展类的功能，或者抽象相应的接口。面向对象的设计原则如下：

　　1.单一职责原则(SRP)-一个类而言，应该仅有一个引起它变化的原因

　　类的职责要单一，类里面的方法只做类的职责范围里面的事情。MVC即是一种粗粒度的职责话费，模型类重点是提供数据，控制类重点是处理业务逻辑，而V视图类则是关注数据获取后的呈现。

　　数据和数据操作可以考虑分解，如形成专门的DTO数据传输对象类。界面类和界面数据提供类也可以考虑分离，如形成专门的Facade层专门负责数据的准备和形成。界面层不应该有太多的数据处理操作。

　　当发现一个大的类里面的属性和方法存在明细的分组特性的时候，而且分组直接松散耦合，需要考虑分解为多个类。

　　引入方法对象来取代方法，当发现一个方法只用到该类里面的几个关键属性，方法和类里面其它的方法交互很少，输出单一。由于该方法和这几个属性内聚性很强而和该类其它部分松耦合，因此可以考虑将方法和这部分属性移出形成一个单独的方法对象。

　　胖接口也是违反职责单一，胖接口会导致所有实现接口的类都Override所有的接口方法，而有些接口方法往往是子类并不需要的。因此对于胖接口仍然要从职责的角度对接口进行拆分。

　　2.开放——封闭原则(OCP)-对扩展开放，对修改封闭

　　当发生变化时，只需要添加新的代码，而不必改动已经正常运行的代码：软件人的梦想!而要达到这个目的，关键是要能够较为准确的预测业务变化会导致的可能会发送变化的模块或代码。

　　3.Liskov替换原则(LSP)

　　子类型必须能够替换掉他们的基类型。正是子类型的可替换性，才使得使用基类类型的软件无须修改可以扩展。案例参考正方形驳论。矩形的合理假设：长、宽可以独立变化;而正方形的合理假设：长、宽始终相等。因此正方形并不能从矩形继承。

　　4.依赖倒置原则(DIP)-高层模块不应该依赖于低层模块;抽象不应该依赖于细节。

　　依赖倒置原则的重点是高层模块类不要去依赖底层模块的类，而应该去依赖接口，特别是当我们预见到底层模块的类本身可能会扩展和变化的时候。这样在变化的时候大的好处是高层类和接口不用变化。

　　类是否考虑抽象为接口，一方面是根据LSP原则进行重构，一方面是需要观察我们建立的类，是否有多个类本身存在相同的行为或方法，如果存在则需要考虑抽象接口。