当前位置: 开发笔记 > 编程语言 > 正文

有C和C++基础，如何提高面向对象的类的设计能力？

作者：手机用户2502885897 | 来源：互联网 | 2024-12-22 19:50

编写了几个500行左右代码的程序，但基本上解决问题还是面向过程的思维，如何从问题中抽象出类，形成类的划分和设计，从而用面向对象的思维解决问题？有这方面的入门好书吗？最好是结合几个具体的案例分析的

编写了几个500行左右代码的程序，但基本上解决问题还是面向过程的思维，

如何从问题中抽象出类，形成类的划分和设计，从而用面向对象的思维解决问题？

有这方面的入门好书吗？最好是结合几个具体的案例分析的。或者要怎么练习？

59 个解决方案

#1

设计模式..

#2

面向对象思想很重要，不是按过程考虑问题，而是大多数都是对象。

#3

面向对象只是一种编程思想。

再抽象的编程语言，最后不都变成汇编代码了吗？我们完全可以说汇编语言是面向对象、脚本化、动态化、泛函化、并行化、分布化的语言。

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。

试对比

图书馆（对图书的分类够结构化了吧）

和

搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）

哪个处理信息更方便、更高效。

所以

与其费劲去重构代码让其看上去更简洁、更合理

不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。

结构越复杂，越难修改，越难除错。

有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。

程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：

◆“要保证这个问题不会再出现，我该怎么做？”

◆“要想少出些Bug，我该怎么做？”

◆“要保证Bug容易被修复，我该怎么做？”

◆“要保持对变化的快速响应，我该怎么做？”

◆“要保证我的软件的运行速度，我该怎么做？”

如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

#4

https://book.douban.com/subject/1052241/

#5

引用 1 楼 akirya 的回复:

设计模式..

引用 4 楼 paschen 的回复:

https://book.douban.com/subject/1052241/

设计模式属于比较高级，不适合入门的吧？

#6

引用 2 楼 lianshaohua 的回复:

面向对象思想很重要，不是按过程考虑问题，而是大多数都是对象。

引用 3 楼 zhao4zhong1 的回复:

面向对象只是一种编程思想。

再抽象的编程语言，最后不都变成汇编代码了吗？我们完全可以说汇编语言是面向对象、脚本化、动态化、泛函化、并行化、分布化的语言。

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。

试对比

图书馆（对图书的分类够结构化了吧）

和

搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）

哪个处理信息更方便、更高效。

所以

与其费劲去重构代码让其看上去更简洁、更合理

不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。

结构越复杂，越难修改，越难除错。

有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。

程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：

◆“要保证这个问题不会再出现，我该怎么做？”

◆“要想少出些Bug，我该怎么做？”

◆“要保证Bug容易被修复，我该怎么做？”

◆“要保持对变化的快速响应，我该怎么做？”

◆“要保证我的软件的运行速度，我该怎么做？”

如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

能介绍有助于面向对象的入门书吗？

#7

引用 5 楼 u010165006 的回复:

Quote: 引用 1 楼 akirya 的回复:

设计模式..

引用 4 楼 paschen 的回复:

https://book.douban.com/subject/1052241/

设计模式属于比较高级，不适合入门的吧？

不要把设计模式想的很高大上

比如java入门时都会接触到这些的。

#8

引用 7 楼 akirya 的回复:

Quote: 引用 5 楼 u010165006 的回复:

Quote: 引用 1 楼 akirya 的回复:

设计模式..

引用 4 楼 paschen 的回复:

https://book.douban.com/subject/1052241/

设计模式属于比较高级，不适合入门的吧？

不要把设计模式想的很高大上

比如java入门时都会接触到这些的。

学校计算机专业或者软件工程专业学习面向对象一般用什么教材呢？

#9

《C++编程思想》

#10

引用 9 楼赵4老师的回复:

《C++编程思想》

.

这本书不是基本讲语法？

#11

《设计模式》

↑我以推荐码农阅读此书为耻！

#12

引用 11 楼 zhao4zhong1 的回复:

《设计模式》

↑我以推荐码农阅读此书为耻！

https://www.baidu.com/s?wd=反设计模式

#13

引用 12 楼 zhao4zhong1 的回复:

Quote: 引用 11 楼 zhao4zhong1 的回复:

《设计模式》

↑我以推荐码农阅读此书为耻！

https://www.baidu.com/s?wd=反设计模式

这个搜索结果很少亚

我觉得设计模式应该是在比较大型的项目中应用，我买了本《大话设计模式》看了几章，看的糊里糊涂都记不住，说明项目经验和代码量不足是难以深入体会的，感觉收获不大难以看下去。个人觉得路线应该是：

Hello world ——> 面向过程 ——> 面向对象 ——> 设计模式

设计模式应该在更高的层次，我现在想学习面向对象。

#14

为什么不推荐设计模式

#15

引用 14 楼 csshow 的回复:

为什么不推荐设计模式

因为实际应用中有很多反模式。

#16

学会virtual大概就可以做抽象了。

#17

先自己练习写写GUI，里面的各个控件都是一个对象，对熟悉面向对象会有帮助

#18

推荐《设计模式》，了解面向对象设计常见动机，意图，目的，以及优缺点和已知应用。

想强化面向对象设计能力，却不懂设计模式，无法与他人交流。

而了解反模式的前提条件是了解设计模式。（大家可以由此推测出一些东西了，不是么？）

选择是自由的，不要附加上其它不相关的东西。

#19

引用 16 楼 qq120848369 的回复:

学会virtual大概就可以做抽象了。

学会做抽象了就可以virtual了

#20

引用 17 楼 wenpinglaoyao 的回复:

先自己练习写写GUI，里面的各个控件都是一个对象，对熟悉面向对象会有帮助

有学了一点BCB，对VCL类库的使用有一点概念，但是自己写程序，难以用面向对象的思维。

#21

《写给大家看的面向对象编程书》

不知此书如何

#22

inside the C++ object

effictive C++

先看后面那本，再看前面那本

#23

引用 3 楼 zhao4zhong1 的回复:

面向对象只是一种编程思想。

再抽象的编程语言，最后不都变成汇编代码了吗？我们完全可以说汇编语言是面向对象、脚本化、动态化、泛函化、并行化、分布化的语言。

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。

试对比

图书馆（对图书的分类够结构化了吧）

和

搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）

哪个处理信息更方便、更高效。

所以

与其费劲去重构代码让其看上去更简洁、更合理

不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。

结构越复杂，越难修改，越难除错。

有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。

程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：

◆“要保证这个问题不会再出现，我该怎么做？”

◆“要想少出些Bug，我该怎么做？”

◆“要保证Bug容易被修复，我该怎么做？”

◆“要保持对变化的快速响应，我该怎么做？”

◆“要保证我的软件的运行速度，我该怎么做？”

如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

说得好

#24

引用 22 楼 dongfangbuba 的回复:

inside the C++ object

effictive C++

先看后面那本，再看前面那本

这两本书跟面向对象关系不大吧？

#25

关键是要有需求，没需求你当然很难想

假如我做个计算器，这个就是需求，也是对象对吧；

首先我得能输入值吧，那么创建变量，比如2个，应付一般的没问题了吧；

还得有个接受值的地方／方法吧，这不是就是输入值的函数，称之为函数１，

然后我总得能加法吧，那么函数２就是将输入的两个值相加，然后给一个返回值；

那么也许我需要把这个返回值显示出来吧，那么函数３，用于显示返回值，顺便，可以再创建一个变量，用于储存这个返回值，于是，函数２也不要给返回值了，调用函数３就行了；

然后我得能减法吧，函数４，接受输入的两个值，减法计算，执行完后调用函数３显示；

我得能乘法吧，能除法吧，那么函数５，６也有了对吧；

我总得能判断究竟执行的是加法还是减法还是乘法还是除法吧，函数７，用于读取用户的选择，到底是哪种，然后调用对应的函数２，４，５，６；

于是，这不就是一个类，有３个变量７个方法，这个类也是一个对象对不对。

我假如需要加法，那么执行函数７，然后通过变量１和２读取输入，再根据条件，调用对应的函数２，函数２执行最后，调用函数３输出结果，这不就ｏｋ了？

没需求你自己空想，那是耍流氓

#26

我推荐《设计模式》，这本书还是可以让我们快速的知道如果把一些常见的需求解耦，日常项目中当然也会有很多地方不用到设计模式，但是其思想和处理手段还是值得学习的。

我个人觉得，面向对象最大的好处就在于解耦，如何把不同的逻辑解耦，使得操作更方便，使用更灵活，扩展性更强。

就是现在很多主流框架做的事情。

#27

引用 25 楼 qq20004604 的回复:

关键是要有需求，没需求你当然很难想

假如我做个计算器，这个就是需求，也是对象对吧；

首先我得能输入值吧，那么创建变量，比如2个，应付一般的没问题了吧；

还得有个接受值的地方／方法吧，这不是就是输入值的函数，称之为函数１，

然后我总得能加法吧，那么函数２就是将输入的两个值相加，然后给一个返回值；

那么也许我需要把这个返回值显示出来吧，那么函数３，用于显示返回值，顺便，可以再创建一个变量，用于储存这个返回值，于是，函数２也不要给返回值了，调用函数３就行了；

然后我得能减法吧，函数４，接受输入的两个值，减法计算，执行完后调用函数３显示；

我得能乘法吧，能除法吧，那么函数５，６也有了对吧；

我总得能判断究竟执行的是加法还是减法还是乘法还是除法吧，函数７，用于读取用户的选择，到底是哪种，然后调用对应的函数２，４，５，６；

于是，这不就是一个类，有３个变量７个方法，这个类也是一个对象对不对。

我假如需要加法，那么执行函数７，然后通过变量１和２读取输入，再根据条件，调用对应的函数２，函数２执行最后，调用函数３输出结果，这不就ｏｋ了？

没需求你自己空想，那是耍流氓

重要的是面向对象通用的知识和思想，而不局限于具体需求。

#28

引用 26 楼 Rewen 的回复:

我推荐《设计模式》，这本书还是可以让我们快速的知道如果把一些常见的需求解耦，日常项目中当然也会有很多地方不用到设计模式，但是其思想和处理手段还是值得学习的。

我个人觉得，面向对象最大的好处就在于解耦，如何把不同的逻辑解耦，使得操作更方便，使用更灵活，扩展性更强。

就是现在很多主流框架做的事情。

我觉得学习设计模式需要很好的面向对象功底，想先学习面向对象思想。

#29

引用 28 楼 u010165006 的回复:

Quote: 引用 26 楼 Rewen 的回复:

我推荐《设计模式》，这本书还是可以让我们快速的知道如果把一些常见的需求解耦，日常项目中当然也会有很多地方不用到设计模式，但是其思想和处理手段还是值得学习的。

我个人觉得，面向对象最大的好处就在于解耦，如何把不同的逻辑解耦，使得操作更方便，使用更灵活，扩展性更强。

就是现在很多主流框架做的事情。

我觉得学习设计模式需要很好的面向对象功底，想先学习面向对象思想。

那你告诉我，什么是思想？思想的定义是什么？

#30

引用 29 楼 qq20004604 的回复:

Quote: 引用 28 楼 u010165006 的回复:

Quote: 引用 26 楼 Rewen 的回复:

我推荐《设计模式》，这本书还是可以让我们快速的知道如果把一些常见的需求解耦，日常项目中当然也会有很多地方不用到设计模式，但是其思想和处理手段还是值得学习的。

我个人觉得，面向对象最大的好处就在于解耦，如何把不同的逻辑解耦，使得操作更方便，使用更灵活，扩展性更强。

就是现在很多主流框架做的事情。

我觉得学习设计模式需要很好的面向对象功底，想先学习面向对象思想。

那你告诉我，什么是思想？思想的定义是什么？

就是如何从问题中抽象出类，形成类的划分和设计，从而用面向对象的思维解决问题。

#31

引用 30楼我是你的主体的回复:

Quote: 引用 29 楼 qq20004604 的回复:

Quote: 引用 28 楼 u010165006 的回复:

Quote: 引用 26 楼 Rewen 的回复:

我推荐《设计模式》，这本书还是可以让我们快速的知道如果把一些常见的需求解耦，日常项目中当然也会有很多地方不用到设计模式，但是其思想和处理手段还是值得学习的。

我个人觉得，面向对象最大的好处就在于解耦，如何把不同的逻辑解耦，使得操作更方便，使用更灵活，扩展性更强。

就是现在很多主流框架做的事情。

我觉得学习设计模式需要很好的面向对象功底，想先学习面向对象思想。

那你告诉我，什么是思想？思想的定义是什么？

就是如何从问题中抽象出类，形成类的划分和设计，从而用面向对象的思维解决问题。

对啊，最后是解决问题，而不是思想

#32

莫非想要的是面向对象分析与设计，入门级的？

《深入浅出面向对象分析与设计》(Head First Object Oriented Analysis and Design)

head first特色，呵呵。

#33

引用 32 楼 cxyOOOO 的回复:

莫非想要的是面向对象分析与设计，入门级的？

《深入浅出面向对象分析与设计》(Head First Object Oriented Analysis and Design)

head first特色，呵呵。

应该是面向对象分析与设计，不过看目录这类书会不会比较枯燥？

#34

听你描述应该是刚入门，现在看设计模式恐怕会很痛苦，虽然实践是最好的老师，但必要的基础还是要有。有很多人都喜欢拿着各种模式下意识的去套，这样很累也不一定真的适用，不过学习了解一下前辈的经验总是好的，我建议你可以了解一下设计模式，看不懂就算了，以后实战多了，自然会有自己的理解，在这个过程中，你就能或多或少体会到什么叫面向对象的设计。

#35

引用 34 楼 falcomavin 的回复:

听你描述应该是刚入门，现在看设计模式恐怕会很痛苦，虽然实践是最好的老师，但必要的基础还是要有。有很多人都喜欢拿着各种模式下意识的去套，这样很累也不一定真的适用，不过学习了解一下前辈的经验总是好的，我建议你可以了解一下设计模式，看不懂就算了，以后实战多了，自然会有自己的理解，在这个过程中，你就能或多或少体会到什么叫面向对象的设计。

对，现在看不懂也记不住，以后有概念了再看也不迟。

#36

引用 33 楼 u010165006 的回复:

Quote: 引用 32 楼 cxyOOOO 的回复:

莫非想要的是面向对象分析与设计，入门级的？

《深入浅出面向对象分析与设计》(Head First Object Oriented Analysis and Design)

head first特色，呵呵。

应该是面向对象分析与设计，不过看目录这类书会不会比较枯燥？

不枯燥，东拉西扯的，俺仅随便翻了翻，没细读过。

head first系列特色就是”梗“特多。漫无目的的新人也许会喜欢，对非新人也许那些”梗“成了啰嗦。

另外head first系列中也有讲设计模式的，有空可以看看。

#37

一个Java设计模式的笑话

大意说，有个人要钉个钉子挂画框，于是去工具店买个锤子。店主说，No，我们已经不卖锤子了。锤子有很多种，大锤、拔钉锤、圆头锤等等，如果你买了一个，之后又发现你还需要另一个怎么办？多数人只想要一把锤子，所以我们推出了万能锤，可以当各种锤子使用。买者想想也是，那就买一把万能锤吧。店主说，No，万能锤已经被淘汰了。你想，万能锤虽然可以当各种锤子用，但它做什么活都没有专门用途的锤子好使。所以，我们开始卖锤子工厂，这样你可以随时制造最合适的锤子。买者说，但我并不想买个工厂……店主说，没错，所以它已经被淘汰了。我们研究发现，不是所有的用户都需要生产所有类型的锤子，所以我们开始卖锤子工厂设计图，这样用户可以根据自己的需要定制工厂。买者说，我猜这个也淘汰了吧？店主说，没错，我们研究发现，用户并不想自己建造一个工厂。于是我们推出了建造锤子工厂的工厂，来帮助用户建造锤子工厂……

#38

世界是我的表象

#39

看再多的书都是没有用的,简单跟你说下吧，靠的是你的想象力还有对这个程序的理解力，缺一不可。c和c++简单的打个比方的区别就是把拆分完的动作再一一的组装成一个模块。另外设计的时候注意高内聚低耦合

#40

引用 39 楼 zhangchenchen2014 的回复:

看再多的书都是没有用的,简单跟你说下吧，靠的是你的想象力还有对这个程序的理解力，缺一不可。c和c++简单的打个比方的区别就是把拆分完的动作再一一的组装成一个模块。另外设计的时候注意高内聚低耦合

有一些经验和知识还是通用的，有指导意义的，不然要理论干什么

#41

把你的代码和变量变量全部写到不同的类里面，久而久之你就习惯了用类对象来思考

#42

引用 41 楼 Co_priest 的回复:

把你的代码和变量变量全部写到不同的类里面，久而久之你就习惯了用类对象来思考

问题是要确定哪些不同的类

#43

过早的优化是万恶之源！

记不得哪位C++大牛在哪本学习C++的书的前言里面说过

“用C语言1000行源码能完成的工作千万不要用C++重写！”

做个可能不太恰当的比喻：

人想让狗帮忙逮只兔子，可是人说话狗听不懂，于是人发明了一种介乎人言和狗语之间的语言，即口令。

人想让电脑帮忙做计算，可是人话电脑听不懂，于是人发明了一种介乎人言和汇编机器码之间的语言，即C语言。

人对狗的口令得让人容易学、也得让狗容易懂。

C语言同样得让人容易学、也得让电脑容易懂。

相比之下C++、Java就是人学得费劲、电脑也经常闹不懂。

#44

引用 42 楼 u010165006 的回复:

Quote: 引用 41 楼 Co_priest 的回复:

把你的代码和变量变量全部写到不同的类里面，久而久之你就习惯了用类对象来思考

问题是要确定哪些不同的类

这个分类很简单，在我的观点众，面向过程就是按照程序流程来设计代码；而面向对象，就是把代码分成一块一块分别放在不同的对象（类）里的。

比如做一个控制台版本的学生管理系统（相信一开始学C或者什么，应该都有做过），就可以把对链表的操作放在一个类，然后再写一个类来对学生信息进行增删查改，然后学生类里面的方法就可以直接去调用链表操作的类；当你要改变链表结构的时候，几乎就不需要对学生操作的类进行改动；类就是一个成员变量和函数集合封装的实体，把要的一些方法放在里面，然后外面要用的时候调用就行了。

怎么划分类可以根据你自己的习惯和代码的可读性或者可操作性等，不一定千篇一律，怎么方便怎么来。

#45

类的划分实际上是有一些规律的，书上说需求总结里所有的名词可能作为类的候选，所有的动词可能是某个类的方法，然后再迭代。没有一定的实践经验，未必能想出合适的。

#46

引用 40 楼 u010165006 的回复:

Quote: 引用 39 楼 zhangchenchen2014 的回复:

看再多的书都是没有用的,简单跟你说下吧，靠的是你的想象力还有对这个程序的理解力，缺一不可。c和c++简单的打个比方的区别就是把拆分完的动作再一一的组装成一个模块。另外设计的时候注意高内聚低耦合

有一些经验和知识还是通用的，有指导意义的，不然要理论干什么

对,我不否认经验和知识有用,但我更承认一个具有丰富想象力的头脑才是创造力的源泉。：p,我们就喜欢成功是百分之九十九的汗水,但是你却不知道你不具备百分之一的灵感,在怎么努力都是不行的。

#47

对不对用户说了算。设计的很多时间是在沟通和试错（理想情况下），所以工程界发明了不少试图降低成本的方法论。

#48

工程活动本来就有技术要求，又不是小孩子过家家。

#49

说白了，所谓的《面向对象》，最终目的是用现实世界的思维方式，解决程序世界中的问题。

#50

引用 49 楼 super_admi 的回复:

说白了，所谓的《面向对象》，最终目的是用现实世界的思维方式，解决程序世界中的问题。

遗憾的是：现实世界的思维方式并不是面向对象。