面向对象思想

对于“依赖于抽象而非依赖于实现”这句话，我一直都不明白，就这一句话让我苦思了一个多星期
之前一直在学C++语言，对于语言的了解我觉得还不错了吧，但是我对于C++语言特性所写的测试代码根本不能让理解这句话。
恐怕这个问题已经超出了语言特性的范围了，我是说只是研究C++语言的范围。
任何一本介绍C++语言的书恐怕最多也只是几个类之间的事情，像C++primer也同样是这样，但是这个问题并不是几个类就说的清楚。
这句话换句话说是“针对于接口编程，而非针对于实现编程”
这句话同样拗口，真正理解他非常困难，异常困难，简直就是一道鸿沟，被这句话折磨过的人恐怕不在少数吧。
真正要有所理解这句话，恐怕没有3，5个项目经验的积累是不行的，而且还不是仅仅局限在一个小小的模块上（因为可能根本用不上）。
这个问题是一个设计上的问题，主要考虑的是系统的灵活性，扩展性和维护性，是一种大局观思想，我所理解的大局观思想是
一种总揽整个系统，甚至是更加上层的一种思维。也就说最低层次也是能掌控整个系统的对象建模。
感觉上似乎有点恐怖，实际上也没那么恐怖，要学的是思想，抽象是一类事物的统称，他可以被具体化，而在C++里面就是表现为多态，在设计上就表现为接口，本质上没什么区别，但是考虑大局观就更复杂些，为了系统更灵活，更容易扩展和维护基本上所有类的根基类都是抽象类，为什么要这么设计？这个思想要是理解了也算是C++学习上的一个里程碑了，甚至可以说不仅仅是C++，对于任何语言都适用。
至于如何理解这个思想，我目前只是有点概念，实在说不出来，让大牛们来说吧

87 个解决方案

#1

”依赖于抽象而非依赖于实现“
换句话说，就是依赖基类而不是具体实现的子类。

#2

引用 1 楼 cxsjabcabc 的回复:

”依赖于抽象而非依赖于实现“
换句话说，就是依赖基类而不是具体实现的子类。

字面意思确实不难哦

#3

  C++面向对象概念里的抽象其实说白了，
就是能把问题或者事物用一种通用的情形来描述或表达，
所以有了基类子类的概念，
在解决一些问题的时候，发现某些类和某些类组合在一起更适合解决这些问题，而且让扩展更方便；
所以这些解决问题的方法、思路和思想被总结和抽象一下就是所谓的设计模式。
  

#4

引用 3 楼 cxsjabcabc 的回复:

C++面向对象概念里的抽象其实说白了，
就是能把问题或者事物用一种通用的情形来描述或表达，
所以有了基类子类的概念，
在解决一些问题的时候，发现某些类和某些类组合在一起更适合解决这些问题，而且让扩展更方便；
所以这些解决问题的方法、思路和思想被总结和抽象一下就是所谓的设计模式。

一点没错，一切基于解决设计问题而来的

#5

项目还得分好几大块呢, 一个块内就那么点东西, 爱怎么设计怎么设计, 只要大块之间通信规定好了就行了.

#6

根据需求来设计..

#7

楼主说的对，没做过几个项目的，对于这些设计模式还真理解的不好；
我也算做过好几个项目了，也有自己的一定理解了，慢慢悟肯定会越来越明白的，呵呵

#8

引用 5 楼 qq120848369 的回复:

项目还得分好几大块呢, 一个块内就那么点东西, 爱怎么设计怎么设计, 只要大块之间通信规定好了就行了.

一听这么说的，无非两种人，一种是牛人，一种是很牛的人

#9

引用 4 楼 qscool1987 的回复:

引用 3 楼 cxsjabcabc 的回复:
C++面向对象概念里的抽象其实说白了，
就是能把问题或者事物用一种通用的情形来描述或表达，
所以有了基类子类的概念，
在解决一些问题的时候，发现某些类和某些类组合在一起更适合解决这些问题，而且让扩展更方便；
所以这些解决问题的方法、思路和思想被总结和抽象一下就是所谓的设计模式。

一点没错，一切基于解决设计问题而来的

对的，没错，基于解决问题而来的。
现在我有一种倾向，做项目写代码时，不画设计图，设计图已在脑中，直接代码搞定。

#10

引用 9 楼 cxsjabcabc 的回复:

引用 4 楼 qscool1987 的回复:
引用 3 楼 cxsjabcabc 的回复:
C++面向对象概念里的抽象其实说白了，
就是能把问题或者事物用一种通用的情形来描述或表达，
所以有了基类子类的概念，
在解决一些问题的时候，发现某些类和某些类组合在一起更适合解决这些问题，而且让扩展更方便；
所以这些解决问题的方法、思路和思想被总结和抽象一下就是所谓的设计模式。

一点没错，……

那看来你只准备干模块了

#11

这里讨论的是思想，咱们只学思想不谈语言，这个面向对象思想咱们就得给它下个定义，什么只可意会不可言传，我从来不信那一套，只不过这个定义你当前什么水平你就只能说出个什么水平，无所谓嘛，在奋斗一段时间在来下个定义，可能就不一样了。

#12

追加到200分了，只盼望能有让人有所感悟的亮点回贴啊

#13

楼主慢悠闲的。呵呵

#14

当编写一个程序时，首先需要考虑的并不是程序的功能如何实现，而是整个程序的逻辑框架，而抽象类就是用来设计这个框架的，也就是你所说得大局。

#15

我现在用MFC做程序，不管什么来了就是根据对话框建一个类，就像函数一样

#16

引用 15 楼 cbzjzsb123 的回复:

我现在用MFC做程序，不管什么来了就是根据对话框建一个类，就像函数一样

你这只不过是很表层的，一种经验式的拖拉点缀，丧失了对代码的控制权

#17

我记得以前在哪看过，说面向对象是骗人的

#18

引用 17 楼 xiaoyuanyuan2009 的回复:

我记得以前在哪看过，说面向对象是骗人的

这个不敢苟同，面向对象是存在的，只不过这些对象有的是反应现实中存在的事物，有的并不是，反应现实事物好理解，反应那种抽象事物就不太好理解

#19

lz想说明什么？
系统的抽象一般都是逐步的
除非这个问题或者这个行业已经有固定的解决模式了
想一次性完成设计？

#20

该回复于2012-01-10 16:27:58被版主删除

#21

针对于接口编程，而非针对于实现编程
好吧，只可意会，不可言传，实践才是王道

#22

引用 5 楼 qq120848369 的回复:

项目还得分好几大块呢, 一个块内就那么点东西, 爱怎么设计怎么设计, 只要大块之间通信规定好了就行了.

我觉得大的系统，通信是很严重的问题，设计的不好通信过程就复杂，添加功能就不容易，C++是静态消息机制，通过函数调用，所以C++本身存在许多问题，还好很多大师设计了许多机制来扩展C++，STL里面的类型萃取，boost里面的函数绑定机制等，只能膜拜

#23

你们在说什么。

#24

看我blog
http://www.cnblogs.com/healerkx/category/136925.html

#25

楼主慢悠闲的。

#26

这个多看看设计模式还是好理解吧，不针对接口来编程的话系统的弹性就太差了
而且针对接口这个需要很多项目经验吗？？想象计算机网络，计算机操作系统这些大系统的设计，哪个不是针对接口进行设计的呢？？

#27

引用 24 楼 healer_kx 的回复:

看我blog
http://www.cnblogs.com/healerkx/category/136925.html

之前都已经拜读过了
现在的目标是系统的对象建模，几个类之间的关系我可以处理的毫无问题，但是大局观还不够，苦恼的是这个

#28

引用 26 楼 rabbitlbj 的回复:

这个多看看设计模式还是好理解吧，不针对接口来编程的话系统的弹性就太差了
而且针对接口这个需要很多项目经验吗？？想象计算机网络，计算机操作系统这些大系统的设计，哪个不是针对接口进行设计的呢？？

在下正是在研读*的设计模式以及软件工程 实践者的研究方法寻找答案

#29

面向抽象编程，关键就四字：“封装变化”，纵观各种设计模式，无一不体现这一思想，如Builder模式，封装对象构建过程，Strategy模式，封装算法具体实现等等

#30

学习了，说得有道理

#31

就是针对接口或抽象类编程，这样一个类的实现改变了不会影响另一个类

#32

java的， 不就是多态嘛

#33

本质上来说，面向对象和面向过程的核心思想是一样的，区别在于面向过程的重点在功能划分，并耦合于函数原型；而面向对象的重点是功能+数据的划分，并耦合于接口，接口就是对象的原型！！！

要注意的接口是划分的产物。如果连对象都没划分清楚，就开始设计接口，最后一定会做不少无用功，弄不好整个软件被糟糕的接口绑架而走上歧途。

对象的划分比功能划分要困难许多，因为功能之间的关系可以表示为堆栈模型，是树状结构（或DAG，递归另算，因为一般不会使用复杂递归），而数据之间的关系则非常复杂，它有两个方面：空间和值（相当于lvalue和rvalue，前者用于引用，后者用于计算），数据的空间关系是一般图结构，值关系则是倒挂的树状结构，这也是为什么在自动化静态分析中，数据分析比过程分析困难许多。而数据的两重特性更加重了对象划分的困难。

这在设计模式里面可没提到，因为那本书是先假设你已经划分好了，然后根据划分的关系给你提供了20多种模式让你选择。如果一上来就先考虑模式，那你就输了。但是在某些显而易见的局部设计中，快速选择一种正确的模式，是条捷径，这也是设计模式这本书的目的。

正是因为对象划分的困难，所以才有重构，因为人不可能总是走在正确的路上。重构实际上是一种把你往正确道路上引导的方法，使得软件在演化的过程中不至于撞南墙也不回头。但是实际的效果还是由人决定的，因为最终是人来选择往哪个方向去重构。

#34

<<敏捷软件开发>>

#35

责任细分、责任归纳、责任组合、责任继承
  
  

#36

离开设计模式谈面向对象有意义？？？

#37

《代码大全》  有好多的抽象方法。自己品味吧。 说不清楚。

#38

to:SonicLing
本质上来说，面向对象和面向过程的核心思想是一样的，区别在于面向过程的重点在功能划分，并耦合于函数原型；而面向对象的重点是功能+数据的划分，并耦合于接口，接口就是对象的原型！！！
感谢你这句让人颇有意味的话，在设计模式上，对象的类和类型是两个完全不同的概念，正和你这里所说的一样。这句话值得回味

#39

其实你已经了解很多了。。。

估计你最近看了这方面不少东西吧？或许你以前也看过、纠结过。。。

过了以一段时间过后，这几天了解的东西可能又会忘掉。。。

看你上面文字的描述，其实已经比较有感觉了，只是从“理论”到“实际”中间的这道鸿沟没有填平，还比较模糊而已。。。

呵呵，以上都是乱猜的，其实我目前就是这个状况。

已经很久没有在csdn上发言了。。。

加油！！！

#40

这个是在大的项目在，你提供接口给别人用，这时候别人只关心你的接口是如何声明的，在C++中接口声明为抽象类，通常有virtual声明的虚函数。这时候别人依赖的就是你的接口了，不是实现。你的实现可以修改，接口可以不改。如果有多种实现，具体用哪个实现一般由接口的使用者去选择，可以在配置文件中写。
你可以看看设计模式吧，会理解很多。

#41

这句话更适合目前中国的教育

#42

引用 40 楼 cattycat 的回复:

这个是在大的项目在，你提供接口给别人用，这时候别人只关心你的接口是如何声明的，在C++中接口声明为抽象类，通常有virtual声明的虚函数。这时候别人依赖的就是你的接口了，不是实现。你的实现可以修改，接口可以不改。如果有多种实现，具体用哪个实现一般由接口的使用者去选择，可以在配置文件中写。
你可以看看设计模式吧，会理解很多。

这句话是为了系统更灵活，更容易扩展和维护吧，对于不需要考虑扩展的地方可以直接把代码写死，对于需要考虑扩展的地方就进行抽象用抽象基类的指针来统一管理派生类，这样只需要添加相应的子类，然后用相应的具体子类指针去初始化基类的指针就可以做到扩展，而不需要修改其他代码。

#43

面向对象编程，面向接口编程，自认为刚刚够入门。。

#44

引用 42 楼 qscool1987 的回复:

引用 40 楼 cattycat 的回复:
这个是在大的项目在，你提供接口给别人用，这时候别人只关心你的接口是如何声明的，在C++中接口声明为抽象类，通常有virtual声明的虚函数。这时候别人依赖的就是你的接口了，不是实现。你的实现可以修改，接口可以不改。如果有多种实现，具体用哪个实现一般由接口的使用者去选择，可以在配置文件中写。
你可以看看设计模式吧，会理解很多。

这句话是为了系统……

给别人用本身就是一种扩展，无需咬文嚼字！！！

#45

引用 29 楼 cuiweican 的回复:

面向抽象编程，关键就四字：“封装变化”，纵观各种设计模式，无一不体现这一思想，如Builder模式，封装对象构建过程，Strategy模式，封装算法具体实现等等

同意，，，，，我看了一下<设计模式解析> 很同意你的观点

#46

实现各种各样的接口是一个很沉重的负担，必要的时候再用。如果每个类都从接口实现起，会很累。有时候强耦合其实也很好，切莫臆造接口，盲目套用设计模式。这是经验之谈。

#47

我也不知道，这个应该是一种编程思想的问题，他貌似是一个从一个项目的基本的架设上处于顶端考虑的吧啊。

#48

引用 27 楼 qscool1987 的回复:

引用 24 楼 healer_kx 的回复:
看我blog
http://www.cnblogs.com/healerkx/category/136925.html

之前都已经拜读过了
现在的目标是系统的对象建模，几个类之间的关系我可以处理的毫无问题，但是大局观还不够，苦恼的是这个

你准备给我分吧，这个事情很好说明白。

说白了就是你去写那些 对象之间的关系（继承-派生关系，Mixin，接口interface，聚合关系），特别是（比如Java程序员会强调其中的接口interface和实现类的关系，Ruby程序员更在乎的是Mixin和继承，C++综合一些）而你在乎更多的是类和类之间，对象和对象之间的“关系”， 而不是怎么实现这样一个类！

比如你写个UI框架，你重视的是View，Button，Window，Canvas这些名词实体之间的关系。
而不是如何实现一个Button本身~怎么渲染Button的内容什么的。

当然了，Java的世界里面，总会强调接口的隔离作用，无论是模块划分上，还是人的分工上。

总之，这些都是类，对象关系的问题，这个比实现更重要。

#49

看来是一门很深的学科，进来围观下~

#50

面向对象的三要素，封装、继承、多态，每个要素能解决的问题就是设计过程中需要充分利用的问题，设计模式中提到那么多的模式大都围着这个转悠，遇到具体需求才能体验了，否则和“三个DB”没什么两样~