是什么阻碍了我对OO的运用！

        写写一些关于技术上的迷茫，胡言乱语几句：面向对象，设计模式的确很强大，但是它的强大只是在书中发现，在某些特定业务背景下运用设计模式，OO恰好完美的解决问题。可是自己在工作中怎么去运用这些。

        三层架构：

         Model定义实体,对应着数据库的表,这一层被其他三个层引用。UI层用于显示，从页面获取参数，包括向数据库插入数据的时候构造实体数据。BLL只是起到一个中介传输作用而已。就这样，Model层对应着那些实体，DAL就对应着对这些实体类的数据库操作的类，而BLL也当然就对应着那些类。这里还有一个题外话，就是BLL是业务逻辑层，业务就是在用户触发后也是要符合某些条件下才能发生的，就像商城购买物品的时候，用户结算订单也是需要用户账户有足够金额才能结算成功的，计算成功后改变订单的状态，扣除用户金额，等等（业务就是在某些条件允许下才能够发生，并且发生后会触发其他业务的产生，或者造成某些影响，改变某些结果）。很多系统就这样分层，就这样做完一个个项目。

        用面向对象的准则来评价一些上面的分层：

        单一职责,也就是一个类应该只是负责做一件事和仅有一个引起变化的原因。这句话是从张逸老师的书中摘来的。但是对于后面一句还是不太理解。但是对于第一句，貌似还是可以套在上面的三层架够中的。例如在DAL中定义一个OrderDAL这个类专门负责对Order实体的SQL数据库操作，如果要再抽象这个类的话，定义将其定义为一个抽象类，对于对数据库操作的方法定义成抽象函数。接下来就是传说中的抽象工厂模式了。这因此也在我脑海里留下一个错误的印象，要运用OO中的封装，继承，多态编写可扩展行的代码是，分析对象只能是上面的三层架构中的实体对象，数据库操作对象，业务逻辑操作对象。

        一直以来有这么一个错误的认识，对象就像是自然界中的一个物质。也就是对象。

        数据库定义表，表的各个字段对应这实体类的各个字段。这里其实一直有一个错误的认识，就是：类就是代表的某一个特定存在对象，会员商品，邮件。也就是说面向对象

类，一定是要在数据库中存在的表。

        在大学最初接触C++的时候，第一接触的类就是一个时钟类，其里面有着时分秒等私有字段。回想一下上面所说的三层架构，Model层只是定义着实体,没有方法，DAL，BLL只是定义着方法没有定义着属性字段。为什么我们不像定义时钟类那样呢？Order类定义者Order的属性，并有对数据库的操作。这样这个类其实就要两个职责了，定义Order所拥有的成员，对Order进行数据库操作。因此需要明白Model层其实唯一的职责就死定义，规范着各个实体应该拥有什么字段。如果我们不使用Model来定义某个实体应该拥有哪些字段，这样我们在调用进行插入订单的时候就需要些大量参数，以来造成不便。

        有上面可以知道我们的DAL，Model是都有其各自职责的。而往往就是我们的BLL层，自责混乱。

        阻碍思路：

        1.一直以为项目中的能运用OO设计为类的知识那些数据实体而已，对应着数据库的表而已。其实这样的看法是错误的。

        2.受限于对三层架构的认识程度还不够深

        3.会有一个错误的直觉，就是一个类库就代表着一个层。类库与层，不是一一对应的，一个类库可以有多个层，一个层也可以在多个类库中的。视具体的情况不同而定的。