面向对象不是万能的

Question

三层架构可以清晰的把系统分解开，Database，Logic,UI
权限如果放到数据库了的话，只定义成职员的一个属性不是很好。
但还要根据你的系统进行分析和设计。转载
今年初我开始持一种在软件开发中采用类似于MS DNA结构开发模式的观点，把软件内部的各个模块分为表现层，逻辑层，数据层（注意：我说的只是一个软件内部各个C＋＋类的组织形式，而不是一个大型系统方案的结构，大型系统方案当然都会采用三层结构），这是当时我看三星的基站网管软件文档忽然得来的一个想法。那时候我挺激动的，想着自己经历了一年多的coding生活，总算由量变到达质变，我先是在水木清华软件工程版或者是VISUAL C++版或者是Programming版上抛出这个论点，马上有网友响应我这个观点，后来好像还收进了精华区（hehe，记不清了，找不到不要骂我哦），然后我开始动手把去年底在教研室做的一个GPS-GSM车载终端监控软件按照这个思路重写一遍，把所有的逻辑处理从各种各样的View/Wnd/FrameWnd里抽离出来，形成写成一个个专用于逻辑处理的类，与文件存储有关的则被我归结到数据层上去，与用户界面有关的当然就是表现层了，这样一来，整个软件结构显得清晰很多，代码易读很多。写完那个软件之后，我对这个想法愈加深信，我开始全面的在自己的软件开发中通盘考虑这种做法，甚至有些过了头走向极端。有一段时间，我无论拿到什么样的project都要从三层上来考虑，A层负责与用户交互，B层负责逻辑处理，C层负责数据存储，几个逻辑模块B1，B2，B3之间还存在一个通信队列，B1负责写队列，B2负责读队列......一开始我就把一个小软件的框架设计得非常庞大吓人，到了动手开始写代码后，我发现自己渐渐无法控制代码了，尽管开始我认为自己的软件结构定的很好了，但还是有很多意想不到的事情，一方面是实际情况很复杂，并不是我设计那么几个表现层、逻辑层、数据层所能解决的；另一方面是过于追求模式，什么样的东西都往三层上套，一个很小的功能，一个类就能解决的，我很硬性的分为两/三层结构，用了好几个类，尽管每个类只有一两个函数，而且这几个类之间的功能并不象所谓的三层那样区别非常明显......我热衷于模式设计，却陷入了形式主义。

Answer 1

呵呵, 教条主义严重
查询合同金额（）-- 这个方法哪个类都可以有,但是关键是每个类的实现方法是不同di,所以产生的效果也是不同di.作为经理,自然可以查询,所以有正确的执行代码.作为职员, 自然不可以查询,所以执行代码可以是空.
提出这个问题, 偶个人以为你对类的重载等等理解不够

Answer 2

如果你让普通总经理由普通用户派生出来，那么你派生的方向是错误的。你应该让用户继承总经理。即特殊——》一般的方向，你可以把特权标以final组织子类的继承。

Answer 3

cyberworm(虫子) ：用户继承总经理？？怎么理解

Answer 4

你可以看一下<uml 与面向对象的程序设计基础>一书。上面关于继承/多继承的方面。

Answer 5

cyberworm(虫子) ：
用户继承总经理？？自然是总经理继承用户
难道生物应该继承自蚂蚁？