面向对象是在业务编码的过程中通过抽象成类、对象及其之间的关系来建模，实现对现实世界的理解和抽象。任何一个概念都会有具体表征来体现，所以我们提到对象就会想到三大特征（继承、封装、多态）其中继承体现的是类间的关系和复用性；封装带来的是类的独立性，易于模块的维护和隔离，降低类之间的耦合；多态表现的是灵活、抽象、行为和代码共享；通过使用三个特征就可以代表着是面向对象的编程？，与之对应的是面向过程编程，通过数据结构+算法的按照逻辑一步一步的实现，或者通过函数进行包装，功能函数间的调用实现系统功能。然后面向对象具体在于6大设计原则，23中设计模式，通过这些原则和设计模式可以解决相似场景的问题，原则和模式体现的就是面向对象的思想？
在实际的开发中，使用面向对象软件开发思想慢慢就变成了把现有业务场景如何通过类的继承、封装、多态来完成，如何使用23中设计模式来套上业务。这是一个过程，理解概要就是要使用这些特性和设计模式体会面向对象的思想，但是拘泥于使用这些特征和设计模式就会对使用面向对象编写的业务代码空有其形，没有达到对现实世界的理解和抽象。整个业务代码编写阅读来和面向过程差不多，只是在代码层面不断的分层、类的方法封装、对象之间的关系仅仅是要相互使用其封装的方法。
在阅读《大象-Thinking in UML》的内容很喜欢其中一段关于UML创始人Grady Booch在大会上提到一个观点“我对面向对象编程的目标从来就不是复用。相反，对我来说，对象提供了一种处理复杂问题的方式。这个问题可以追溯到亚里士多德：您把这个世界视为过程还是对象？在面向对象兴起运动之前，编程以过程为中心，例如结构化设计方法，然而，系统已经达到了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的，更复杂的系统-我认为，这才是面向对象编程运动的真正胜利。”，这一段话给我的感触是面向对象真实意愿是在面对复杂性极点的问题可以相对好处理，所以要求其进行抽象，对现实世界的抽象建模，通过代码的设计可以让看代码的人理解这个所表达的现实业务。这样的解决业务问题，可以是对复杂问题的极简单处理。
比如面对业务场景是三张数据填报（全周期、年度、月度），三者都是有版本号、创建的人和时间、更新的人和时间，各自的填报内容；填报的过程要首先创建一份数据、维护数据（编辑、删除）、提交数据；填报规则是上一个填报通过内容是下一个的依据。业务大致是这一个过程。首次面对可能是对三者依次建立类对象，然后封装各自方法，方法内填满业务规则，对象互相调用，最后是实现要求，但是没有真实体现业务，所以重构一下，三张数据表在现实世界其实都是是静态的填报文档、填报的过程就是操作数据表的过程，静态的数据表本身是不会进行这些操作，都是通过人为的进行操作。所以在设计时候，定义一个静态类，其具备的仅仅是填报内容，其主要起到的是表征意义，这是一份数据表；然后定义一个操作Handler，通过的这个Handler操作数据表，完成其整个流程。
// 抽象的数据表
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace TQF.SelfBussines { /// <summary> /// （报表抽象） /// </summary> public abstract class SelfBusinessReport { /// <summary> /// 版本号 /// </summary> public string VersionNo { get; set; } /// <summary> /// 分期Id /// </summary> public string StageId { get; set; } /// <summary> /// 创建人 /// </summary> public string CreateBy { get; set; } /// <summary> /// 创建时间 /// </summary> public DateTime CreateDate { get; set; } /// <summary> /// 更新人 /// </summary> public string UpdateBy { get; set; } /// <summary> /// 更新时间 /// </summary> public DateTime UpdateDate { get; set; } /// <summary> /// 报表状态 /// </summary> public int Status { get; set; } /// <summary> /// 报表维护状态（0初始化，1编辑保存、2删除报表、3历史记录）使用策略模式，依据不同的状态做不同的维护操作 /// </summary> public int ImproveStatus { get; set; } } }
// 操作类Handler
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace TQF.SelfBussines { /// <summary> /// 报表填报接口（行为契约） /// </summary> public interface ISelfBusinessHandler<T1,T2>where T1:ICreateReportData where T2:SelfBusinessReport { /// <summary> /// handler维护填报项 /// </summary> T2 Report { get; set; } /// <summary> /// 创建报表 /// </summary> /// <param name="createReportData"></param> /// <returns></returns> ResultBase CreateReport(T1 createReportData); /// <summary> /// 维护报表 /// </summary> /// <returns></returns> ResultBase ImproveReport(); /// <summary> /// 提交报表 /// </summary> /// <returns></returns> ResultBase SubmitReport(); } }
例子很简单，但是向表达的是如何更好的将业务通过面向对象的思想编码，面向对象的三个特征和设计模式都是服务于这个思想，而且这个设计也不是唯一的答案，可以有很多设计方案，就看那个方案是最接近业务。
每天我们都在面向对象编程，但是如何面向对象编程确实是值得思考的一个问题。面向对象可能带来代码量的增多，类和对象量大的问题，所以至于是使用面向对象或者面向过程，如何抽象，抽象层度都要依据具体的业务。
参考《大象-Thinking in UML》
原文：https://www.cnblogs.com/tuqunfu/p/14359972.html