首页 > 代码库 > Java对象设计通用原则之核心原则
Java对象设计通用原则之核心原则
即不能存在多于一个导致类变更的原因。简单的说就是一个类只负责一项职责。
让一个类仅负责一项职责,如果一个类有多于一项的职责,这是比较脆弱的设计。因为一旦某一项职责发生了改变,需要去更改代码,那么有可能会引起其他职责改变。所谓牵一发而动全身,这显然是我们所不愿意看到的,所以我们会把这个类分拆开来,由两个类来分别维护这两个职责,这样当一个职责发生改变,需要修改时,不会影响到另一个职责。
public class CommonUtil { #region Canvas Helpers public void M1() { } //... #endregion #region Screen Helpers public void M2() { } //... #endregion #region Size Helpers public void M3() { } //... #endregion #region Data Helpers public void M4() { } //... #endregion }
各位,你觉得这个类写的怎么样?
软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。
这条原则是所有面向对象原则的核心。
public class Component { public enum Status { None, Installed, Uninstalled } Status m_status = Status.None; void Do() { switch (m_status) { case Status.None: Console.WriteLine("Error..."); break; case Status.Installed: Console.WriteLine("Hello!"); break; case Status.Uninstalled: Console.WriteLine("Error..."); break; default: break; } } }
我们这里定义了一个组件,用户动态加载,加载完了以后程序就可以用了,为了处理方便,我们给组件定义了一些状态,在不同的状态下,这个组件有不同的行为,于是就有了上面的代码:enum定义状态,函数中使用switch实现路由。
public class ComponentStaus { public virtual void Do() { } } public class ComponentNone : ComponentStaus { public override void Do() { Console.WriteLine("Error..."); } } public class ComponentInitialized : ComponentStaus { public virtual void Do() { Console.WriteLine("Hello!"); } } public class Component { ComponentStaus m_status = new ComponentNone(); public void ChangeStatus(ComponentStaus newStatus) { m_status = newStatus; } public void Do() { m_status.Do(); } }
在上面的例子中,我们发现了变化点,然后抽象出一个基类放在那,然后使用继承机制,让子类去演绎变化。当我们需要添加新的状态Configured的时候,我们只要添加一个新的子类ComponentConfigured,让它从ComponentStaus继承,并重写Do方法即可。使用的时候,在合适的时机(如事件处理中)把该子类的实例传给Component就可以了,当然也有可能是Component自己处理事件或方法时自己修改该状态实例。
任何基类可以出现的地方,子类一定可以出现。
LSP原则是继承复用的基石,只有当派生类可以替换掉基类,软件的功能不受到影响时,基类才能真正被复用,而派生类也能够在基类的基础上增加新的行为。
public class Program { static void Main(string[] args) { Rectangle rect = new Rectangle(); rect.setWidth(100); rect.setHeight(20); Console.WriteLine(rect.Area == 100 * 20); Rectangle squ = new Square(); rect.setWidth(100); rect.setHeight(20); Console.WriteLine(squ.Area == 100 * 20); } } class Rectangle { public double m_width; public double m_height; public virtual void setWidth(double width) { m_width = width; } public virtual void setHeight(double height) { m_height = height; } public double Area { get { return m_width * m_height; } } } class Square : Rectangle { public override void setWidth(double width) { m_width = width; m_height = width; } public override void setHeight(double height) { m_width = height; m_height = height; } }
很显然输入的不是两个True,根本原因就在于正方形只有长的概念,而没有长方形所期望的宽的概念,所以长方形中定义了正方形根本没有的东西,也就是说长方形不应该是正方形的基类。
不能强迫用户去依赖那些他们不使用的接口。换句话说,使用多个专门的接口比使用单一的总接口总要好。
这一原则与单一职责原则息息相关,它们对于高内聚的追求是一致的,但是它更加强调了接口的高内聚性。
interface IService { void GetUser(); void RegisterUser(); void LoadProducts(); void AddProduct(); void AcceptRequest(); void SendResponse(); }
因为是面向所有Client的,所以这个接口提供了所有Client需要的方法,比如用户的操纵,产品的操作,数据传输的一些操作,每个Client都可能用到其中的一部分服务。
interface IUser { void GetUser(); void RegisterUser(); } interface IProduct { void LoadProducts(); void AddProduct(); } interface IPeer { void AcceptRequest(); void SendResponse(); } class Service : IUser, IProduct, IPeer {}
这样拿到代理对象后,想处理用户的Client,将该对象转换成IUser即可,想处理产品的转换成IProduct即可。
1、高层模块不应该依赖低层模块,两者都应该依赖于抽象(抽象类或接口) 2、抽象(抽象类或接口)不应该依赖于细节(具体实现类) 3、细节(具体实现类)应该依赖抽象
总结起来,这个原则说的就是每个类与别的类交互时,尽量只使用满足接口规范的抽象类。为啥?因为抽象类实现细节几乎没有,没什么需要变化的。这一条深刻揭示了抽象的生命力,抽象的对象才是最有表达能力的对象,因为它通常是“无形”的,可以随时填充相关的细节。
public class Program { static void Main(string[] args) { UI layer = new UI(); layer.SetDataAccessor(new XmlDataAccessor()); layer.Do(); } } class UI { DataAccessor m_accessor; public void SetDataAccessor(DataAccessor accessor) { m_accessor = accessor; } public void Do() { m_accessor.GetUser(); } } interface DataAccessor { void GetUser(); void RegisterUser(); } class XmlDataAccessor : DataAccessor { public void GetUser() { } public void RegisterUser() { } }
这里上游的组件UI依赖的是DataAccessor这样的接口,而不是依赖各种具体的子类,如XmlDataAccessor,这样当想使用其他的数据库存储数据的时候,只要增加新的DatabaseDataAccessor之类的新类,然后在设置的时候设置一下就可以了。这种手段,很多人也称为"依赖注入"。
Java对象设计通用原则之核心原则