果然被淘汰了，和我想的差不多，原因是我觉得它太复杂了，我喜欢那种一看上去就清晰简单的东西，而且要容易理解。一个好的架构应该可以抽象成现实生活中有的“东西”，这样理解起来就容易多了。
我学“面向对象设计”的时候，发现一个问题，那就是对象的“方法”问题，比如对象要是人的话，他有一个“提交”，或者是“检查”的方法，那是很容易理解的。但是比如有个“表单类”，其中他的方法“添加”。我觉得它这个方法是“被动”的，因为表单自己并不会“添加”，施加给它这个“动作”，或者是“方法”的，应该是个人。所以我认为，我们建模的时候为什么不把一个过程抽象为现实生活中的过程呢，也许它的性能会低一些。虽然我还没有具体去实践，也还没有学过什么J2EE，但是我把我的想法说说：
比如架构一个系统，要涉及到权限，要涉及到功能的“开”，“关”，最基本的做法，我们做每一个操作之前，总是要查询“这个功能被系统打开了或者是关闭了没”，“我们是不是有这个权限”，很自然的，比如是个注册系统，我们在执行“添加”这个动作之前，都必须用到两个方法，第一个检查这个“注册”功能是不是正被开放使用，第二个，我们是不是有这个“权限”进行“添加”操作？那这两个类，我们应该放在哪个类里面去呢，也许我们可以把他分成两个类（权限类，功能类），然后在“注册类”里面加上这两个方法，在执行“添加”之前操作他们。我觉得这样增加了他们之间的“耦合”，也显得很混乱，在一个类里面执行这些操作，是不是把“注册类”这个静的东西动态了？执行这些操作的应该是个人才对啊？就象在现实世界中，我们填写完一张注册表之后，我们并不会直接去“检查”，“添加”他，我们会把他交个一个这方面的人，然后这个人会检查，我是不是有这个权限？我填写的完整没有？然后他跟“注册类”打交道。也就是,用户――>“负责注册模块的人”――>注册类。这样打交道。
权限和功能问题：我们要进行操作时，先找个负责这个操作的人，然后他告诉我，比如，“这个功能被关闭了”，“你的操作已经成功了”，之类，我们不直接跟类打交道，因为我们不能充当每方面的“专家”
这样做的好处，松耦合，也省的每次执行操作之前都要在方法里面嵌套方法，我们可以等用户登陆的时候，就找到那个相关的人，把系统的功能开放了哪些和这个人可以进行的操作记录在表里，进行操作的时候就不必再查数据库了，应该更快些？然后用户退出的时候，就删除相关的记录？
我觉得MVC模式里面的C，有时候他就充当了“这个人”的角色，但其实这个人可以分的更细些。
这些问题我也是刚想的，你们的想法是？或者，说说这样做的缺陷
|
|