面向对象的疑问?

[hyper110]

按照面向对象的原则,设计类时是以现实中的对象为单位,而不是以功能进行分类.

但是我感觉真正要要设计类时,为类分配职责的时候还是,是以功能为类分配职责啊.请高手指点迷津

[hyper110]

能不能从分析功能然后产生对象,这是面向对象的设计吗

[mintwlf]

楼主还没有懂什么叫面向对象呢！

面向对象主要是从参与系统运行的各个角色入手进行分析，功能固然是要实现的，但是具体分析的时候开始是想系统由哪些部分构成，他们是怎么样交互的，这样就会慢慢划分定义出许多对象，他们相协作作来完成整个功能。

其实对于功能本身来说它也是一个对对象。所以现在软件的模式大致如下：

class CFunction //功能类定义
{
//实现功能的对象声明
public：
CFunction();
~CFunction();

Function1();
Function2();
Function3();
//各种功能的定义
FunctionN();
};

[stonespace]

系统中有哪些对象，一种方法是在需求或者实现方案的描述中，寻找名词或者名词短语，每个名词一个对象/类；另一种方法是使用设计模式，引入模式中的类。

需求分析的时候，会描述系统应该实现那些功能，对功能的描述通常是做什么，核心的词应该是动词，但是类来自于名词，功能描述中的名词通常是动词宾语，这些名词对应实体类，功能描述中默认主语是系统，系统当然也可以建模为一个类，是最终的控制类。

除了从需求中找对象，还可以从实现描述中找对象，对一个功能如何实现的描述中，也会有名词和动词，名词可以作为对象，动词可以作为方法。

这些方法得到大量的实体类，但是业务逻辑通常很复杂，控制类只有系统通常是不够的，可以用Facade模式划分层次，得到比较小的控制类。当然也可以使用其他设计模式组织业务逻辑。

[stonespace]

这个问题很奇怪，设计中有哪些对象和功能无关，但是功能都是由对象的方法来实现的，两者并不矛盾。

设计中应该是先有对象，然后才决定每一个功能由哪些对象来实现，这不是以功能作为依据为对象分配职责，而是以一些原则作为依据，把功能分配给对象，对象所实现的那部分功能即对象职责的一部分。

[w_rose]

好的设计最初往往是“自顶向下”地说明的，也就是首先用简单的语言说明目标，这与功能分解相当。不过，你总应该“多说几步”才能清楚地表达你的意思。例如：不能仅仅说“讲故事”而要说出“敬一个关于什么题材的、配合什么情绪的故事”或者更明确，这就要求你（独特地）知道“存在什么”而不仅仅是一个口号。

程序代码是依赖于它处理的数据信息的机构的。这个“数据”已经不是简单的计算机二进制数据，而是业务。对这种结构的改变会造成程序大量重写。

表现力强的程序总是将面向业务的、非常清楚的类型数据作为接口，并且程序操作过程尽量简短。这样的程序是“成文自明”的。非常“经院式”的程序员才会整天拿纯粹计算机领域才有的对象当作研究各种功能的对象。

[w_rose]

面向应用领域去设计程序结构，这也是结构化的基础。结构化也部分是面向对象的基础。面向对象并不是创造了对象概念（对象这个概念恰恰应该算是结构化的大成、必然），而是创造了一种方法，僵化的对象分解以及功能分解方法不再是唯一的设计手法，而是说明对象本身是可以抽象和扩展的（例如：“马”设计好了以后，“白马”就从其扩展而来，他们是同一个实体的在程序中的两种表现，程序控制系统必须帮助维持他们的统一性，同时又能让针对“马”的所有操作“多态”的扩展到“白马”上），因此对象设计、流程设计等等都可以用扩展的眼光去看。

[w_rose]

注意，在面向对象系统中，马是白马的抽象，白马是马的继承，而并不是说白马是马的组成成分。程序分析、设计和运行时程序控制系统（例如接口和操作的转换、装配等）都是为了这个观念而设计的。

面向对象系统使得复杂系统的设计过程从概念上（而不是从实物上）区分成层次，然后进一步扩展。一些复杂的控制系统，各个组件中间的关系有成千上万，把组件抽象成几种对象之后，就能够将这些关系用“一张纸”轻易地设计出来。

[xuzhenhua21]

慎用继承!

[autoegg]

粗浅的理解：
第一步是RM分析，习惯常用UseCase，其中Actor是至关重要的概念，其次才是分析系统应该具备的功能并“责任到人”。

[asj]

w_rose(w_rose) ,你的解释好像有些误导啊？此外是你自己写的么？

[w_rose]

在非常简单的程序中，面向对象反而是要多花时间的。简单而功能强东西其实需要花很多时间才能熟练，最容易粗浅模仿的反而是繁琐复杂的噱头。

此外是不是我自己写的有什么大碍？

[w_rose]

随便举出例子都能说明知识多么需要继承，不熟练他们怎么应付这个知识爆炸的时代，我简直无法理解竟然会有脱离现实的理论工作者还能研究现代的编程和设计理论。例如，为什么对集合可以实现foreach方式？为什么用户定义控件拖动到设计器上就能自动生成代码？为什么我们今天的程序几乎都是“事件驱动”的？连最基本的编程手段都已经全面面向对象了，为什么设计技术必须停留在简单结构式小学生阶段？

[asj]

主要是因为在你的三段回复中关于结构化和面向对象的说明似乎是有些问题的。另外，面向对象的3大特性在这个说明中似乎过于偏重于继承。行文中又不太象是一般回帖的时候写的。所以想和你再讨论讨论
如果是你写的，那么可以请你说的更明确一点，如果不是的话也可以一起探讨一下这段说明究竟是否准确。没有什么其他的意思。

[w_rose]

面向对象的3大特性是什么呢？难道有面向对象之前有人写出符合“标识唯一性”的数据结构（奇怪，我真想问哪一种业务结构在内存中的映射物做不到这一点？）就立刻是面向对象了吗？我没有去重复很自然必须要有的基础的特性，这并不是去否定面向对象的所谓“大特性”。

[asj]

呵呵，不知道是不是我前面的问话显得不太礼貌，w_rose(w_rose)兄似乎有些生气啊，如果是这样，我先在这里表示歉意了。
面向对象，如果按照教科书中的说法，有封装，继承和多态的特性。其实这个里面的继承并不是十分明确，因为有实现继承和接口继承的区别，而接口继承又和多态有重复。现在比较提倡的是：面向接口编程，责任倒置，开闭原则。尽量用组合而非继承。这些内容在你的解释中只出现了继承，而且是一个很含混的“扩展”，所以我觉得有必要再讨论一下。
不是很清楚你在上面的回帖中“标识唯一性”和面向对象有什么关系。如果是我没有了解到的话，望不吝赐教。
还有前面你的帖子里说知识需要继承，设计技术还停留在简单结构式小学生阶段的话我是的确没有看懂。如果你觉得有必要的话可以说明一下。

[w_rose]

封装才是非常含糊的。当年面向对象技术在中国刚刚兴起的时候曾经将这个概念炒过一阵子，“标识唯一性”仅仅是明确地说经任何对象用一个系统化的方式标识出来（代表它的整体），这“封装”或者“元”之类的玄而又玄的东西其实没有什么区别，是同一个东西。

论坛不同于课堂上的教条，远不需要抠字眼，而应该仔细地讨论内容，相信你也同意这样的观点。

我用一种“排比句”提了三个浅显的问题，我认为一定会用“只要具有xxxx接口或者xxxx机制的对象就能处理”这样的话来回答。这样的结构的话对“小学生”是看不懂的，因为它并不会在设计技术的问题上去理解这种“继承、扩展”式的东西。但是，现代的编程技术和开发环境（随便看看.net或者j2ee）根本就是要求人们具有理解这种语法的能力的。

[w_rose]

因为它并不会在设计技术的问题上去理解这种“继承、扩展”式的东西
---------------------------------------------------------------
因为它并不会在涉及技术的问题上去理解这种“继承、扩展”式的东西



意识是说这种回答本身就是要求你去扩展技术模式的，没有那种自己动手去继承和扩展它的能力是无法理解的。

[asj]

封装含混在哪里？
封装无非是说：
1，内外有别，只有给你用的你才可以用，不想让你知道的我可以藏起来。这个结构化的设计中也有类似概念。
2，数据和操作封装在一起，通过对象把一组相关的数据和其上的操作结合起来，外界应该使用这个整体而不是分散的数据和函数。这个概念的进一步发展就是面向接口编程中只有接口的服务而不存在“数据”的概念。这个是结构化设计中没有的，而且，如果有较深的结构化背景，往往会绊在这个问题上无法前进。这也是我不同意你说对象是结构化设计自然而然“集大成”就能得来的。
没有很多的资历，所以不清楚当年这个概念是怎么炒过一阵的，也不清楚和“元”又有什么关系。
还有你那3个问题，和扩展技术模式有什么关系呢？
还有，什么叫做“自己动手去继承和扩展它”，继承什么，扩展什么，什么叫做继承和扩展？

[mach]

封装，继承和多态,这是OOP提出的所谓三大特点,其实这三个特点只是从很底层去看OO,如果只考虑这三个特点,那么面向对象不过是一种设计和编程的技巧,而算不上是一种思想(或者说是分析问题的一种方式)了.
OO和结构化的方法的区别在于看问题的角度和方式的不同.