你觉得没有真正的理解OO概念。

作为设计方法，实际上是要求你首先以OO的概念去看待问题，把问题抽象成一个个Object以及他们间的关系。

况且你这里列举的多半是实现的手段，而非设计，何以得出“作为设计方法则有他不足之处”？

不好意思，我是在用实现来解释设计，我的意思是说某些设计导致了这种实现。

那么J2EE的分层设计还有意义吗？为什么还要分成WEB层、业务逻辑层...呢？

作为设计方法，仅仅把问题抽象成一个个Object以及他们间的关系就能够实现良好的设计吗？（注：问题是不能抽象成1个个对象的，应该是分解；抽象是将具有共性的事物综合成某个类；我不是在做文字游戏，而是看到了概念上的错误，如果你真正明白抽象的概念，你是不会这么用的）。

    public synchronized void setAlignment(int alignment) {
  switch (alignment) {
    case LEFT:
    case CENTER:
    case RIGHT:
      this.alignment = alignment;
          LabelPeer peer = (LabelPeer)this.peer;
      if (peer != null) {
    peer.setAlignment(alignment);
      }
      return;
  }
  throw new IllegalArgumentException("improper alignment: " + alignment);
    }

2. I agree, use it with caution.

[/qoute]
如何才能小心呢？那些情况一定不能用，那些情况一定要用？

1. This is really not right. OCP: Open for extension, closed for modification. So "作为设计方法，实际上是要求你首先以OO的概念去看待问题，把问题抽象成一个个Object以及他们间的关系。"

These layers are above Objects, or objects are in layers.

dog72 wrote:
考虑如下代码（摘自java.awt.Label），如此漂亮的代码不用switch怎么写的出来？我实在看不出不用switch的理由，也不知道不用switch怎么设计。有人能够给出比这好的实现吗？

dog72 wrote:
能给出例子吗？我希望回答都是量化的，能够易于理解的。比如说：是不是说可以用派生RichText的手段来解决刚才增加方法的手段？
如：PrintableRichText, DisplaibleRichText, DisplayAndPrintableRichText ...?

要开发一个RichText类，如果需要显示，就在里面加一个dispaly的方法，如果需要打印就加一个print的方法，如果需要xxx就加一个doXXX的方法。这是不是就OO了，这样就方便了。

dog72 wrote:
不知道这算不算OO的设计方法？如果不算，那是不是能说OO的设计不是我们优先考虑的，是不是要优先考虑层次化设计（这在早期的面向过程的设计，如C和汇编的设计时就已经非常流行了）？

floater wrote:
In this case, you don't need inheritance just because it's simple(for speed). However, if you can foresee that each case is going to grow, then it would be better to break the switch into subclasses. When you make a decision on which way to go, you should take care of all aspects, not just one. As a general programming principle, we should embrace changes, rather than resist them. One way to help us is to isolate changes. In this case, if you foresee you are going to change that switch a lot, you don't want the change to propagate to the rest of the class. If not, just use it, without harm. Martin Fowler, in his book Refactoring chapter 1, gives an excellent example for taking out switch.

I don't see 如此漂亮的代码, just a switch, .

speeddemon wrote:
这位大哥，我不知道为什么总有人喜欢狭隘的定义某一种技术（方法、现象、anything else...），难道你不能把Layer本身视作抽象层次更高的、粒度更粗的Object吗？与细粒度的设计一样，层与层之间仍然是一个职责分担以及如何交互的问题。
对不起，我的话写得不严谨，或许我应该这样表述：
就我本人而言，我认为所谓"以OO概念看待问题"以及我理解的“OO方法”是指：在现实的基础上、在不同的层面上、遵循不同的粒度标准抽象出若干Objects，这些Objects分担有不同的职责，并且通过Objects之间的交互和其他关系，实现将问题域映射到解域的过程。

并且，请恕我再一次指出，你所列举的全都是实现层面的问题。

speeddemon wrote:
补充一下：
实现层面的问题的确有可能反映出设计的问题，但是这不是一个严谨的逻辑推定，更不能以此为由证明OO本身存在问题...

请注意，我并不认为OO是什么Silver Bullet，只是你的论证明显的没有命中要害。实际上我认为使用一种方法来实现某个目的时，最重要的不是方法本身，而是你要达到的目的。方法是可以变通、发展、甚至来一个改头换面的，拘泥于某些定义而不能自拔，是典型的Over-Engineering的表现，也是对方法本身没有吃透，不能灵活运用的表现。

最后再声明一点，我本人自认为对OO的理解是非常浅薄的，但是我认为如果能以我之昏昏，而使人昭昭，不亦乐乎？

zhongyijie wrote:
第四点：XP并不是0设计，而是简单设计，让设计尽量简单，方便以后重构。如果什么设计也没有，重构很麻烦，还不如全部推倒从写。

How does swing handle printing?

floater wrote:
Yea, I would say so. Design components/layers first. They could be implemented in any language, through any design methodologies. Java has packages, right? Using OO doesn't mean to drop everything else.

dog72 wrote:
floater真是老道呀，这不是逼着我来说吗？可我是提问者呀，我也不知道你是同意还是反对。好吧，那我就陈述一下我的观点。
1。如何设计一个对象是首先和你的系统需求是相关的（我的习惯是自底向上设计，这样可以保证最小的时间代价，所以你看到我在设计对象，而很多人采用自顶向下实际上从来没有将设计细化到对象过），awt和Swing的需求是固定的，因此它不适合与RichText进行类比（虽然Swing中有RichText，但是你看到拿个商业的软件使用的是Swing的RichText?)。因为需求是固定的，所以我们可以将print是设计到AWT和Swing中去，这样做的好处是为使用这个工具包提供友好方便的程序界面。
2。如果我们改变Swing的需求，说“Swing要能够生成各种不同格式的文档”，换句话说：要求有一个方法叫printTo(int docType)，docType可以是已知的、未知任何可能的表现形式（呵呵，如果这么真的定义函数可不好，很有可能你的程序员真的去用switch实现）。那么你还能认为print应该定义在Swing中吗？
3。其实RichText就是一个非Swing的需求，因为我既要打印、Paint还要输出到PDF,DOC,PS,WPS,HTML...，甚至还要从这些格式导入；将来可能还要考虑XML，SVG...；那么，要如何设计这样的对象呢？呵呵，我说了我只是提问，答案要大家来回答。
注：RichText编辑器的设计是非常好的考察一个人设计能力的试题，有兴趣大家可以试试。

dog72 wrote:
Using OO doesn't mean to drop everything else. 好！但是实际工作中真的所有人都理解这句话吗？我们还用RichText作为例子，我将print方法写到RichText中当然是OO的做法，我并没有违背OO的原则，但是你却说我做了不恰当的封装，你说我没有将DOC和VIEW分开，难道我用OO的方法来设计我的对象有问题吗？

dog72 wrote:
朋友，我们是在讨论问题。我的目的很简单，大家耳熟能详的概念或理论，是不是真的理解了，任何问题要以科学的态度去看待。如果你能够准确的量化OO的概念和标准，请你show出来我们共享。至于你用一句话来下定义，我有很多疑问，比如什么是现实的基础，什么是不同层面，什么是Object，怎样叫分担职责？定义可以下，但要严谨，科学的方法是去量化你的陈述中的每一种不确定的东西。我在这个贴子中更多的是提问，一开始的论点我并不是要去证明，我只是为了引起大家的关注。
关于实现层面还是设计层面的问题，实际上是要看你的设计细化到什么程度。一个好的设计人员首先是一个熟练的实现人员，至少我认为软件行业是这样。什么是设计？我认为设计就是在你的脑子里去实现。

dog72 wrote:
Using OO doesn't mean to drop everything else. 好！但是实际工作中真的所有人都理解这句话吗？我们还用RichText作为例子，我将print方法写到RichText中当然是OO的做法，我并没有违背OO的原则，但是你却说我做了不恰当的封装，你说我没有将DOC和VIEW分开，难道我用OO的方法来设计我的对象有问题吗？

speeddemon wrote:
指出一点逻辑错误：未违背OO原则的设计并不等于正确的、好的设计！
这个简单的逻辑再清楚不过了...

恕我愚鲁，实在不明白“并没有违背OO的原则”怎么可以证明你的封装是恰当的？难道不违背OO原则就等于恰当的设计？
说你做了不恰当的封装又是怎么和OO方法本身挂上钩的？那是你使用有问题并非OO方法有问题啊！汗......

speeddemon wrote:
我觉得我已经表述得很清楚了，关于你的疑问，我解释如下：
1、什么是现实的基础？
现实的基础指的是任何设计都不可能脱离现实而存在，现实中的种种制约必须在设计时得到体现。例如，拥有哪种档次的硬件可能会影响设计；客户的时间要求也可能会影响设计；开发团队的技术路线、技术能力、经验、默契等等对设计人员来讲全都是必须考虑的现实的制约。
2、什么是不同层面？
不同层面指的是你看待系统的不同抽象层次，在不同层面上，设计人员看待事物、考虑问题的粒度是不同的，表现为设计的对象、阶段不一样。例如，在较高的抽象层次上时，粒度是较粗的，设计时关心的问题是系统需要实现哪些功能，这些功能如何分配到不同的承担者，各个功能的承担者之间如何通信，如何协作，怎样完成一次业务操作？诸如此类，以Layers的形式或者以Package 、subsystem的形式考虑这个层面的职责承担，具体取决于实际情况了。
3、什么是Object？
good question！关于Object的定义有很多，我只能说说我的理解。我觉得Object就是对现实的一种抽象，object拥有完成某项职责的能力，通常来讲objects需要互相协作来完成某种功能，系统就是这样一些object的集合，设计就是抽象出objects及其关系的过程。
4、怎样叫分担职责？
在上一个问题中已经说明白了。

dog72 wrote:
提一个小小的建议，自己下定义之前先看看别人的。

关于OO的java的解释：
Object-Oriented
This is, unfortunately, one of the most overused buzzwords in the industry. But object-oriented design is very powerful because it facilitates the clean definition of interfaces and makes it possible to provide reusable "software ICs."
Simply stated, object-oriented design is a technique that focuses design on the data (=objects) and on the interfaces to it. To make an analogy with carpentry, an "object-oriented" carpenter would be mostly concerned with the chair he was building, and secondarily with the tools used to make it; a "non-object-oriented" carpenter would think primarily of his tools. Object-oriented design is also the mechanism for defining how modules "plug and play."

The object-oriented facilities of Java are essentially those of C++, with extensions from Objective C for more dynamic method resolution.

The folks at Archimedes had lots of things in their simulation, among them ropes and elastic bands. In their initial C version of the product, they ended up with a pretty big system because they had to write separate software for describing ropes versus elastic bands. When they rewrote their application in an object-oriented style, they found they could define one basic object that represented the common aspects of ropes and elastic bands, and then ropes and elastic bands were defined as variations (subclasses) of the basic type. When it came time to add chains, it was a snap because they could build on what had been written before, rather than writing a whole new object simulation.

摘自：http://java.sun.com/docs/overviews/java/java-overview-1.html
另外：
An OOP language sees a car as an integration of its behaviors -- the functions -- and the variables that hold the car's state -- the data values. The integration of state variables and behaviors results in an object. You create that object simply, at the same time initializing the variables. At any time, the object-oriented program identifies the object it wants to work with and calls the object's functions. Essentially, the object-oriented program thinks in terms of objects (e.g. cars) -- not in terms of separate functions (e.g. parking) and variables (e.g. number of doors).

The integration of state variables and behaviors into objects is called encapsulation. Encapsulation promotes information hiding -- a concept that facilitates program maintenance by hiding state variables and behaviors that don't need to be externally accessed -- and is one of the three fundamental principles of OOP. (I'll explore the other two, inheritance and polymorphism, in later series articles.)

忘了出处了。
我不是想引经据典，但是经典的还是要看的。

dog72 wrote:
当然是有逻辑错误，我完全同意你的说法，我就是把问题极限化了（OO=正确的设计）。所以我要说的是局部的OO并不能解决设计的问题，也就是说我在print RichText的时候考虑的封装没有错误，是符合OO原则的。但对于全局者来说，这个封装就会有问题。
那么随之而来问题就来了：怎样才能协调全局和局部，OO可以吗？

speeddemon wrote:
好了。dog72兄，我不准备再在这个问题上再跟你较真了。再讨论下去会变成纯粹的口舌之争，对你我以及论坛上的其他人都无益处。
如果要讨论，还是回到正题上来吧。