一些思维的碎片(二)

       抽象，在百度百科里面的定义：从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征。从这个定义上看，抽象是一个过程，因此抽象似乎是一个动词。但是经常能听到这样的定义就是，XX太抽象了，设计时要依赖于抽象。抽象又成了形容词和名称。噢，这个似乎扯远了。桌子有很多种，圆桌，四脚桌子，思酌，木桌，但是统一叫做桌子，这其实就是一个抽象的过程。抽象的目的：1.通过找出共性的东西，帮助人类更好的认知客观事物;2.实现区分,通过抽象将桌子和椅子，筷子分离开。

        那么程序设计中的抽象又是什么，目的又是为何？在设计过程中，我们经常提到的就是抽象出一个类，接口，要依赖于抽象。事先撇开这个先谈软件设计的几个重要点。

        软中设计中几个重要点：1.Don't Repeat YourSelf,不编写重复的代码，复用代码 ;2.分而治之，分离关注点，也就是通过隔离和分解，将复杂度逐渐缩小，将可变和不可变的进行隔离，将策略和机制的实现进行隔离; (DRY原则，KISS原则，单一职责，SOC，正交性.......)

       上面的key word就是重复，分解，隔离，这似乎和第一段讲到的抽象的目的开始有关系了。为消除重复我们必须进行抽象，根据抽象粒度的大小可以得出一个子程序，一个类，一个接口；通过隔离分离关注点出现了粒度更大的层，出现了分层的思想。

        进一步探讨，设计过程中我们究竟是对什么抽象？按照上面一段的说法，似乎是职责(Responsibility)，但是这样对吗？对于OO的设计实现方法，抽象出类和接口似乎符合上面提到的抽象的定义，但是对于根据职责抽象出一个子程序呢？这个说法貌似错误，这也是过程化思维和OO思维的差异？根据冒号课堂那书所说，将这种称为参数化的抽象？

        Booch 书中提到的三类软件设计方法：Top-down structured design、Data-driven design与Object-oriented design。现在很多项目中使用到的数据库为中心加上事务脚本的实现方式，是否可以称作是Data-driven design，因为表驱动设计时有些数据结构貌似和关系型数据库的表与表之间的设计有着某种说不出的关联？比如代码大全第十八章中讲表驱动设计时所提到的那个获取消息，打印消息的列子，典型的子父表，一对多的设计思想。那么又开始纠结这样一个问题了，这是否关系型数据库的提出联系？关系型数据库er图的设计按照说法是建模。而表驱动的设计思想是通过数据来管理实现设计过程中某些复杂逻辑的对应关系通过表的对应关系进行管理。

数据库设计时是不是其实已经解决了我们潜在的业务逻辑处理，，关系型数据库的设计究竟能解决什么问题，又不能解决那些问题？

       如果说数据库为中心加上事务脚本的实现方式，可以称作是Data-driven design那么这种设计方法在应对什么样的需求，什么样的项目时开始呈现弊端？进而引发出Object-oriented design的设计理念？