怎么把系统抽象化？
最近在看一些设计方面的知识，也看了一些面向对象设计中对事物抽象的概念。

但是我有些疑惑，看书上的例子，觉得他抽象的很是理所当然，但是我发现把这些概念移植到自己的系统的时候却有点糊涂了。

比如我的系统中有经销存的模块。

我想把他抽象化，怎么理解呢？

我是这么想的，不管是采购订单，库存入库单，还是销售订单，库存出库单。

我想他们都应该抽象成同一类事物，都有，增加（Add()）,删除（Del()),修改（Update())等方法，

他们是不是应该都继承一个接口（IBill）呢？这个借口包含增加（Add()）,删除（Del()),修改（Update())

而我们每个单据的类都应该实现这个接口的方法。

疑问来了，

这些方法都带有参数啊，而这个参数都是对应于每个表的实体类Modle，

如果参数定义不一样，是不是又说明他们的共性不存在呢？

呵呵，我就有疑惑了。。。

------解决方案--------------------
如果是进销存的系统，请参考会计基本记账原则

所谓的抽象，不是让程序员去考虑如何操作数据库，而是让程序员去还原现实。

废话不多说了，回头看你的系统

1.采购订单，库存入库单，还是销售订单，库存出库单------这些实际都是业务凭证，不需要程序员多考虑，通通继承于业务凭证类即可

2.业务凭证只是凭证，相关业务逻辑 按会计记账原则称做会计分录

3 会计分录的前提是相关业务的业务科目，比如：材料采购，产成品销售，原材料库存，半成品库存，在制造品库存，成品库存，待入库材料采购库存

4 建立基本业务科目的分录关系 比如：
待入库材料采购订单：从现金账出，入待入库材料采购库存
已入库材料采购订单:未入库材料采购库存 出 ,入原材料库存
生产业务领料：在原材料库存 出，入在制造品库存
半成品入库：在制造品库存 出，入半成品库存
成品库存：在制造品库存 （+半成品库存） 出，入成品库存
======================
通过这些可以建立一些基本恒等式

5：记住一些基本会计结算准则，期末余额=期初余额+当期增加-当期减少

通过上面实际可以看出来 基本就是两个大的抽象类，一个是原始凭证类，一个是分录科目类

然后还有一个分录操作类。

class 原始凭证
 {
凭证类型
分录操作
凭证本身的数据信息
 }
------解决方案--------------------
抽象不是想象出来的,是根据具体情况重构出来的,
抽象属于实现细节层面的内容,抽象是为了维护和扩展方便
设计的时候不要考虑抽象,先想好怎么用,最好在你的方法还没有写的时候就把客户端的代码写出来,从上往下一层一层地实现,在这个过程中寻找抽象点,这样写出来的系统里才简洁,才能做到不废话连篇
总的来说意思:抽象不是目的,是过程,一开始就想怎么抽象注定了失败!
------解决方案--------------------
举例吧：

首先就可以抽象一个“订单”类，下面有两个子类：“采购订单”和“销售订单”。

“订单”就一定有共同的属性，比如:订单号、货物数量、总价等；

而“采购订单”就多了一个属性，比如叫做 Flag, 在采购订单的构造函数中就把它设为“采购”；
同理“销售订单”的Flag设为“销售”；

“订单”的行为一定包含一个 “下订单”，抽象出来，而由“采购订单”和“销售订单”分别实现。

再进一步，可以做一个“订单工厂”，负责产生 各种不同的订单实例，这里就可以用反射来实现了……



不需要代码吧？需要代码的话回个话。
------解决方案--------------------

探讨

引用:
举例吧：

首先就可以抽象一个“订单”类，下面有两个子类：“采购订单”和“销售订单”。

“订单”就一定有共同的属性，比如:订单号、货物数量、总价等；

而“采购订单”就多了一个属性，比如叫做 Flag, 在采购订单的构造函数中就把它设为“采购”；
同理“销售订单”的Flag设为“销售”；

“订单”的行为一定包含一个 “下订单”，抽象出来，而由“采购订单”和“销售订单”分别实现。

再进一步，可以做一个“订单工厂”，负责产生 各种不同的订单实例，这里就可以用反射来实现了……


不需要代码吧？需要代码的话回个话。
好人啊。。

你真的有这方面的经验吗？

我想请教你哦。。

------解决方案--------------------
人们始终在追求对世界的统一描述（我认为这个词比“抽象”更启发灵感）：
1、在我们的项目中（就拿进销存举例），我们可以用一句话统一描述客户的需求：处理 数据，
我在做需求分析的验证的时候有个准则：就是如果存在没有处理的数据或者没有数据的处理都表示需求分析有疏漏；
2、为数据建模：这个楼主没问题，你可以把这些模型叫做Model；在后继的步骤中（注意：不是当下）数据库的表将映射这些Model；
3、为处理建模：可以叫做method，他们由params（或者叫inputview，只要知道是双工的就行）、outputview构成，params和outputview可能会是model的映射，所以你还需要建立联动机制，使得修改model后相应的params或outputview能自动更新，但是逻辑上model和method是一体的，这在需求分析时以表述过
4、我不确定是否对楼主有帮助，所以暂且到此
------解决方案--------------------
如果您考虑的是 增加（Add()）,删除（Del()),修改（Update())等方面，

那么就不要去想什么对象、实体类了，这样只能让你越想越迷糊，在错误的方向越走越远。

增删改，这是数据操作，那么就要从数据库、SQL语句方面来考虑。这才是正确的方向。

您可以到这里来看看，也许能帮上你一点忙。

http://www.cnblogs.com/jyk/
------解决方案--------------------
国是一个含蓄的民族，处对象一般都得通过一个介绍人。
这是一本阐述微观设计的书，而不是阐述宏观设计的书。
《Java与模式》首先阐述了代码的设计原则，又描述了怎样来创建一个类或对象，紧接着告诉大家怎样来组织这些类和对象来实现功能。它是设计模式，而不是架构模式。
OO面向对象编程，实质上是面向抽象编程，即面向接口编程。所谓的面向接口编程，指类之间都要使用接口来通信。类来封装对象的行为，接口来封装类之间的通信方法，接口是更高层次的抽象。这里的接口可以是一个具体类，一个抽象类，或是一个Java接口，它不单单指Java接口。
第四章： 开闭原则

抽象化：面向对象设计的重要原则是创建抽象化，并且从抽象化导出具体化。具体化可以给出不用的版本，每一个版本都给出不同的实现。 

1。开闭原则
一个软件应该对扩展开放，对修改关闭。