面向对象编程(面向过程与面向对象的区别在哪)

面向对象编程，面向过程与面向对象的区别在哪？

首先，面向对象编程语言和面向过程编程语言都是操作计算机的方式，从本质上来说也都是操作计算机执行任务的工具，只是方式上的不同而已。

面向过程编程语言故名思议，以业务流程为考虑问题的出发点，从上到下按照解决问题的流程来组织代码结构，把功能封装成函数，然后依次调用就可以了。所以，面向过程的编程方式往往具有更为清晰的代码流程。面向过程的编程在早期业务逻辑比较单一的时期是非常适合的，而且面向过程的编程语言往往有更高的执行效率，典型的代表就是C语言。当前，C语言在嵌入式开发、操作系统开发领域依然具有广泛的应用。

随着软件开发的复杂化，软件编程需要解决的逻辑问题越发复杂，此时面向对象编程语言就出现了，面向对象语言的主要特点是“抽象”，形成了类、对象、封装、继承、多态等一系列面向对象的概念，这些概念的使用使得开发大型的业务逻辑系统更加方便和可行了。Java是典型的面向对象编程语言，目前也是IT行业内应用最为广泛的编程语言之一，在Web开发、大数据开发、后端开发和Android开发领域都有大量的应用。

简单的说，面向过程以解决问题的单一思路为出发点，而面对对象则以多角度解决问题为出发点，所以面向对象的编程要更加复杂一些。从学习的角度出发，学习面向过程的编程语言要稍微容易一些，毕竟函数式编程更容易理解。在学习面向对象编程语言的时候，在学习的初期会具有一定的困难，困难在于要理解一系列抽象概念，所以不少人都说，学习面向对象编程就是学习“抽象”。

我从事互联网行业多年，目前也在带计算机专业的研究生，主要的研究方向集中在大数据和人工智能领域，我会陆续写一些关于互联网技术方面的文章，感兴趣的朋友可以关注我，相信一定会有所收获。

如果有互联网方面的问题，或者考研方面的问题，都可以咨询我，谢谢！

go模块化编程和面向对象区别？

结构化编程是针对汇编那种方式的去掉了goto等让程序看起来很乱的语法，讲究的是顺序结构化；面向对象是类的思想，通过继承多态等实现程序共享，更适合大型程序的编制，当然小程序也适合的，而且很不错，建议多多理解下

面向对象的编程方法为什么使用起来不理想？

我感觉确实应用不理想，很多程序员，有些都是资深程序员了对于面向对象的概念仅仅停留在技术层面上。程序员还是没有理解面向对象的基本概念，即使使用类似Java这种工具，也很难提高效率，更何况Java也被程序员带得走形了。

关于面向对象，我会写一系列文章介绍如何认识世界，可以先读以下两篇，感兴趣加关注。

软件架构师必读：面向对象编程思想（OOP）的由来与本质

软件架构师必读2：一文带你理解面向对象(OOP)中类的本质

我总结了一下，当前理解上主要有这几个原因：

对于面向对象在系统分析中的作用不掌握，还没有掌握拆分对象、属性和方法的基本原则，对于继承的理解不足，对于重载、多态和接口存在滥用现象。项目筹划仓促，没有业务专家的加入或者业务变化比较大，拆分不好对象的设计不仅不能省力，还会给后期的更改造成麻烦。具体工具语言实现过程中，例如Java和Python，也没有对面向对象提供明确使用规范。反倒是产生了“优先使用组合而不是继承”这样的经验，这是技术上开倒车了。......

当然问题还有很多，但我看了许多面向对象的文章，发现困扰程序员，甚至是资深程序员的主要问题是对世界的认识不正确，就是问题1，不掌握的根源在于对世界缺乏认识论。这里说的认识论包括分类、属性、关系、方法、结构.....等要素之间的关系分析能力。

几乎随便找出一篇面向对象的文章，你都可以发现最主要的问题出在根源上：认识世界不正确。

我举个例子大家就明白了：

我们公司说180天以前的发票不给报销，这是自然语言，一句话就说清楚了。但是引入了一个词叫“发票”，发票包含火车票、住宿票、出租车票、停车发票、饭费发票、旅游发票，发票有个属性叫做发生日期，

if 填单日期-发票.发生日期> 180 天 then 显示("发票日期超过180天不予报销")

......你看，要是没有发票的这个指代作用，我们要费好多话。

一个好的面向对象的程序就是要做到概念（指代范围）明确、逻辑清晰、语句精简。这样才好维护好更改。

两篇别人面向对象的小例子，你有别的文章要分析也可以发给我，我感觉大部分问题都出现在例子上，就是对世界的认识方法上。

例子一：

前几天看了一篇讨论Java面向对象的文章，其中举了一个例子：如何将水生动物、陆生动物、食草动物、食肉动物进行分类，如果把他们都做成动物类的继承，你会发现有的食草水生动物不知道往哪儿放。最后决定动物是类，把食草、食肉，水生、陆生都做成接口，然后问题就成功得以解决。

如何对水生动物、陆生动物、食草动物、食肉动物进行分类，其实你仔细想一下，我们学过的动物学中有水生动物这个类别么？并没有！有什么动物类别么？你想起来初中生物学中哺乳动物的主要特征么：胎生、哺乳。没有这两个特征就进入不了哺乳的类别。

那我们怎么表示水生动物这个集合啊？别着急，集合是一定要通过类别表示么？类别也可以通过属性表示。设置一个生活环境属性：

水生动物={动物| 生活环境=水}

属于对象和属性的分析不合理。

例子二：

在另一篇文章中，设计了这样一个继承关系：也是推导了半天，最后得出结论面向对象不好使。

我们来看一下，父亲和孩子是实体么？这个是对象么？，每个有孩子的人都是孩子，一个老人能管他叫孩子么？那他曾经是孩子怎么办？他对于他父母来说始终是孩子吧？......逻辑晕得一塌糊涂。这么分析是不会有结果的。

我们跳出来看一下，实体应该是人，实例是具体的人。父亲和孩子是实例之间的一种关系。认识到这一层就知道要把父亲和孩子分别做成人的方法：如果是get，返回参数就是找当前对象的父亲和孩子。

小结一下：

如何认识世界、分析世界是一门学问，叫做本体论，是面向对象的哲学基础。

学习语言和语文对编程至关重要，说到底编程语言还是语言，语言就有自己的规律和特点，抓住规律才能事半功倍。

博士聊IT，感兴趣请关注！

「博士聊IT」一文看懂编程的本质，程序员有前途么？

程序员比社平工资高70%？编程的本质是什么？能力强还是分配不公

低代码无代码平台的未来在哪里？编程语言的进化史告诉你答案

软件架构师必读：面向对象编程思想（OOP）的由来与本质

中国为什么没有自己的编程语言？哲学、数学和语言学基础是关键

面向对象OOP是编程语言发展中的弯路吗？

一切皆对象的口号显然有点过了，但也不至于说走了多少弯路。这个问题跟「子类型（subtyping）是不是错误（ill-defined）的东西？」有点类似，就是程序员突然发现工具箱里面有些工具没了的话好像也没关系，就开始怀疑它们是不是多余的或错误的设计。OOP是个模糊的概念，它不仅仅指程序语言的那些特性，OOP之前必须先OOD （Object Oriented Design），不可能脱离OOD谈OOP，如果只谈概念，我们来看看：封装：到底什么是封装？私有方法？那 Haskell 只导出 Smart Constructors 算不算？继承：OCaml module include 算不算？Typeclass hierarchy 算不算？多态：参数化多态也叫多态啊！如何才能划出一条清晰的边线界定OOP？对象内部状态？这可就麻烦大了，所有非纯函数式编程都不可能完全避开内部状态。如果你就是要原教旨 Pure FP 大法好？那……你开心就好：type MonadStackHell a b c = AppT (MaybeT (ReaderT a (StateT b IO))) c不要跟我提Extensible effects，既然Haskell都只能做到这种地步，为什么它就不算走弯路？有些人不爽的地方可能在于，数据和行为是两个不同的维度，而现有的OOP语言都把数据和行为绑定到了一起，不得不用 Extensible Visitor Pattern 绕弯。可这本身就是难解之题，Haskell 里面虽然可以很方便地用 Typeclass 扩展方法，但添加新的数据却成了问题。Data types à la carte 那种方式虽然可以无限扩展数据，但却增加了转型的运行时开销，鱼和熊掌不可兼得，OOP 语言选择了另一条路，但子类型虚函数又会增加方法调用的运行时开销。（我也不提 Object Algebras 只从编程语言角度思考就进入了死胡同，我们要从OOD的角度看。在设计时自然说 A student is a Person，继承了Person的属性和方法，Haskell不支持Record继承，难道在设计时也说Student包含一个Person？然后白板上 Functor、MonadTrans、Constraints 满天飞？这样看将 Subtying 和 Inheritance 捆绑在一起还真是非常贴心，要是只说Student是Person的子类还不够，还要加一句Person有的ABCD接口Student都继承实现，那就太啰嗦了。对象思维方式显然更易于描述现实中的大部分业务模型。它有它的局限性，但离泛滥还远着呢，我看到更多的是很多程序员根本不懂面向对象设计，甚至根本就没有 Design 这一步，从这方面来讲，不但不算是弯路，甚至还应该继续大力推进。问题的关键并不在于OOP，而在于错误的OOD。如果OOD本身就是错的，那么正确的又是什么？我觉得现在我们还不能完美回答这个问题，有一个词呼之欲出： Language Oriented Design，但是我们还有很多路要走，而且我很怀疑有些业务逻辑天生更适合用OOD描述，换成LOD只不过是重新发明一个OO DSL而已。