关于OO的一点困惑？大家来讨论一下好吗？

[ycshowtop]

最近一直在做一个项目的分析，今早来上班的车上突然有一点想法，

很想知道大家在系统设计时的作法，因为我做这行不是很久。

假如有一件事情，可以有两种方法实现：

一种是纯的OO，把很多很复杂的问题封装在一个对象中，外面让用户觉得它是一个很简单的东西。但是程序员要实现这个对象，或是你自己要设计它的内部实现机制就觉得挺困难的。

一种是OO加过程，封装不彻底，给用户的接口有点复杂，但是对象内部实现起来较容易，条理也清楚。

这两种设计你会倾向于哪种？

虽然没有分可给的，但是还希望有人能发表自己的看法。

[llshore]

个人意见：
倾向于第一种，具体执行时，
1、功能细分，细到一定程度时，很多对象之间的功能是可以互用的，可以起到一定的通用性；
2、抽象性的对象共同点归纳，以继承或接口定义等方式降低对象的粒度，可以适当降低对象设计的复杂性和提高设计效率；
3、对象可以是个递归式的（抱歉，不知如何表达更合理）概念，就是说，一个大规模的对象可以由任意层次、任意数量的小型对象组合而成（当然不可能无所限制），而小型对象的设计难度应该是不会大到哪去的。

请指教。

[Augue]

考虑一：
取决于你对，时间，性能，成本的限制。
如果没有限制，那么采用第一种。
考虑二：
取决于你手头上的资源；
如果什么资源都没有 && 没有 考虑一 中的限制。
那么也是 采用第一种。
如果有丰富的资源（过程的），那么采用第二种。

[xujiaqiang]

实际上可以做到两全其美，关键是按从客观现实的角度考虑，合理地进行功能划分，底层的对象
往往很简单，复用性好，如果将它的访问接口公开(public)，就实现了第二种。
例如你要向数据库保存数据，必须先使用系统的功能，建立数据库连接、设置连接参数，
打开连接，设置命令，运行命令等，这些访问接口都是公开的。但你可以设计一个DBMgr对象，
将所有这些操作封装在DBMgr中，用户可直接通过DBMgr来访问数据库。但并不妨碍用户使用
原来的方法以增强灵活性。这就是设计模式中的facade模式，建议找一本设计模式的书看看，
会有很大提高，尤其是factory和facade模式。

[ycshowtop]

推荐一本好书吧，多谢！！！

[notyy]

看看设计模式中的Facate(外观）模式不就知道了？这个模式为复杂的子系统提供一个高层的接口（外观）方便用户使用，同时对少数懂得如何使用底层功能的人，它并不隐藏这些功能。

[xujiaqiang]

http://www.umlchina.com/的模式中下载

[GreatBug]

要看这个东西给谁用。

[024h]

倾向于第一种，一般用户不大愿意使用过于复杂的软件，另外，往后考虑，在维护、复用上考虑，
业以第二种为佳。

[zzroom]

倾向于第一种。可能实现时较繁，但维护等费用将降低。