用户的属性（Properties）和用户的行为（Behavior）没有分开，这是一个严重的错误！非常正确，确实是这个接口设计的一团糟，应该把用户的信息抽取成一个业务对象(Bussiness Object,简称BO)，把行为抽取成另外一您的设计模式到另外一个接口中。
使用：
PI pUser = new User();
pUser.setName("nick");
//接口转义
BI bUser = (BI)pUser,
bUser.say("hello");
2、里氏替换原则【Liskov Substitution Principle】
向下转型是不安全的，子类可以扩展父类的功能，但不能改变父类原有的功能。
class Father
function(a,b){return a-b;}
class Son extends Father
function(a,b){retrun a+b;}
main:
Son s = new Son();
s.function(100,20);
在实际编程中，常常会通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的几率非常大。
一、子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
覆盖（重写Override）：方法名.返回类型,参数类型和参数个数都要求和父类中的一样.
重载（Overload）：方法名和方法的返回类型都相同,但方法参数不一样
二、 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
参数扩大：当向下转型时，依靠参数范围自动匹对执行父类方法，而不是一直执行子类方法，参数缩小：当向下转型时，优先匹对的是子类方法，父类有可能是抽象类，子类是实现类，若传递了一个较大范围的参数时，就会去匹对父类方法，而父类方法是抽象类，这时程序将会报错。
三、覆盖或实现父类的方法是 输出结果可以被缩小
1、重载：子类参数扩大
2、覆盖：子类参数和父类相同，父类为抽象方法
四、 子类覆盖的方法不能比父类被覆盖的方法的访问权限更严格
三、依赖倒置原则【Dependence Inversion Principle】
A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体，具体应该依赖于抽象。
随着时间的推移，越来越多的类型必须加入到系统中，模块将会被if/else语句弄得很乱，它最终将变得僵化、脆弱
四、接口隔离原则【Interface Segregation Principle】
接口尽量细化，同时接口中的方法尽量的少。
接口要高内聚。具体到接口隔离原则就是要求在接口中尽量少公布public 方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。
定制服务。
五、迪米特法则【Low Of Demeter】
对类的隔离原则（大致同四）
六、开闭原则【Open Close Principle】
（1）对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。
（2）对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。