扫一扫下载手机客户端
扫描我，关注团购信息，享更多优惠
||网络安全
| | | | | | | | | | | | | | | |
||电子电工
汽车交通| | | | | | | | | |
||投资理财
| | | | | | | | | | | | | | | | |
| | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
||外语考试
| | | | | | | | |
| 视频教程|
Python 3面向对象编程
全面介绍Python强大的面向对象编程特性，是详尽的教程，包含丰富的实例。
定价：￥79.00
校园优惠价：￥61.62 (78折)
促销活动：
商品已成功飞到您的手机啦！快登录手机站看看吧！
下载客户端
> 微信关注“互动出版网”，便捷查询订单，更多惊喜天天有
ISBN：3上架时间：出版日期：2015 年7月开本：16开页码：380版次：1-1
所属分类：
　 -通过一步步的教程来学习如何在Python中应用面向对象编程。-通过抽象、封装和信息隐藏来设计公共接口。-通过学习Python语法把你的设计变成可以工作的软件。-通过使用特定的错误对象来触发、处理、定义和操纵异常。-通过实际例子在Python中实现面向对象编程。-理解什么时候使用面向对象特性，更重要的是，什么时候不用。-学习什么是设计模式以及为什么它们在Python中是不同的。-揭示单元测试的简单以及为什么它在Python中如此重要。
Python 是一种面向对象的解释型语言，面向对象是其非常重要的特性。《Python 3面向对象编程》通过Python 的数据结构、语法、设计模式，从简单到复杂，从初级到高级，一步步通过例子来展示了Python 中面向对象的概念和原则。
《Python 3面向对象编程》不是Python 的入门书籍，适合具有Python 基础经验的开发人员阅读。如果你拥有其他面向对象语言的经验，你会更容易理解《Python 3面向对象编程》的内容。
Dusty Phillips 是一名加拿大自由软件开发人员、教师、武术家以及开源爱好者。他和Arch Linux 社区以及其他开源社区有着紧密联系。他维护着Arch Linux 的门户网站以及编译了流行的Arch Linux 手册。Dusty 持有计算机科学人机交互方向的硕士学位。他目前在自己的计算机里安装了6 种不同的Python 解释器。
肖鹏，毕业于北京理工大学信息与通信工程专业，2011年起就职于思科系统（中国）信息技术服务有限公司，是一名网络咨询工程师，具有多年Python网络开发经验。个人博客： http://www.pythoner.io/ GitHub：xiaopeng163
常贺，毕业于北京邮电大学计算机科学与技术专业，现就职于思科系统中国公司高级服务部门。他具备多年的网络监控管理系统的开发经验。
石琳，思科系统（中国）信息技术服务有限公司网络咨询工程师，具有多年python开发经验，目前从事SDN方面的技术工作。
第1 章 面向对象设计 ........................................ 1
面向对象 ........................................ 1
对象和类 ........................................ 3
指定属性和行为 ........................................ 5
数据描述对象 ............................... ........................................ 5
行为是动作 ........................................ ........................................ 7
隐藏细节并且创建公共接口 ........................................ 8
组合和继承 ........................................ 10
继承 ........................................ 12
案例学习 ........................................ 15
练习 ........................................ 22
总结 ........................................ 23
第2 章 Python 对象 ........................................ .. 24
创建Python 类 ........................................ 24
添加属性 ........................................ 26
让类实际做一些事情 ........................................ ... 26
对象的初始化 ........................................ 29
解释你自己 ........................................ 32
模块和包 ........................................ 34
组织模块 ........................................ 36
　　这本书将向你介绍面向对象范型的术语，通过一步步的例子，专注于面向对象的设计。它将带你从简单的继承开始，这在面向对象程序员工具箱里是最有用的工具之一，到最复杂之一的合作继承。你将能提高、处理、定义以及操作异常。
　　你将能够把Python 面向对象和不是那么面向对象的方面结合起来。通过研究高级的设计模式，你将能够创建可维护的应用程序。你将学习Python 复杂的字符串和文件操作，以及如何区分二进制和文本数据。将会介绍给你不止一个，而是两个非常强大的自动化测试系统。你将会理解单元测试的喜悦以及创建单元测试是多么简单。你甚至会学习像数据库连接和GUI 工具包这样的高级库，以及它们是如何应用面向对象原则的。
　　这本书讲了什么
　　第1 章，面向对象设计覆盖了重要的面向对象概念。它主要处理关于抽象、类、封装和继承。在建模我们的类和对象时，我们也简要地看了下UML。
　　第2 章，Python 对象讨论了类和对象，以及它们是如何在Python 中使用的。我们将学习Python 对象中的属性和行为，以及把类组织成包和模块。最后我们将看到如何保护我们的数据。
　　第3 章，当对象是相似的让我们从更深层次的视角来看继承。它覆盖了多重继承以及向我们展示了如何从内置来继承。这一章还包括了多态以及鸭子类型。
　　第4 章，异常处理讲解异常和异常处理。我们将学习如何创建自己的异常。它还涉及了把异常用于程序流程控制。
　　第5 章，何时使用面向对象编程主要处理对象，什么时候创建和使用它们。我们将看到如何使用属性来包装数据，以及限制数据访问。这一章也会讨论DRY 原则以及如何不重复代码。
　　第6 章，Python 数据结构覆盖了数据结构的面向对象特征。这一章主要处理元组、字典、列表和集合。我们也会看一看如何扩展内置对象。
　　第7 章，Python 里面向对象的快捷方式顾名思义，在Python 中如何省时。我们将看到很多有用的内置函数，然后继续在列表、集合和字典中使用解析。我们将学习关于生成器、方法重载，以及默认参数的内容。我们还会看到如何把函数当成对象来用。
　　第8 章，Python 设计模式1 第一次向我们介绍了Python 设计模式。然后我们将会看到装饰器模式、观察者模式、策略模式、状态模式、单例模式以及模板模式。这些模式将会和在Python 中实现的合适的例子和程序一起讨论。
　　第9 章，Python 设计模式2 讲解上一章剩下的内容。我们将通过Python 中的例子看到适配器模式、外观模式、享元模式、命令模式、抽象模式以及组合模式。
　　第10 章，文件和字符串学习字符串和字符串格式化。也会讨论字节和字节数组。我们也将会学习文件以及如何从文件读取数据和往文件里写数据。我们将学习存储和pickle 对象，最后本章会讨论序列化对象。
　　第11 章，测试面向对象的程序以使用测试和为什么测试如此重要开头。重点是测试驱动开发。我们将看到如何使用unittest 模块，以及py.test 自动化测试套件。最后我们将使用coverage.py 来看代码的测试覆盖率。
　　第12 章，常用Python 3 库 集中介绍库以及它们在程序构建中的利用率。我们将使用SQLAlchemy 来构建数据库，使用TkInter 和PyQt 开发用户界面。这一章会继续讨论如何构建XML 文档以及我们应该如何使用ElementTree 和lxml。最后我们将使用CherryPy 和Jinja 来创建一个Web 应用。
　　对于这本书你需要什么
　　为了编译运行在本书中提到的例子，你需要下面的软件：
　　Python 3.0 或者更高的版本
　　py.test
　　coverage.py
同类热销商品￥35.00￥24.50
订单处理配送
北京奥维博世图书发行有限公司 china-pub,All Rights Reserved面向对象编程的弊端是什么？
【冯东的回答(72票)】:
面向对象的弊端在于作为一种建模技术没有很好的定义自己的适用范围。面向对象脱胎的环境有两个重要因素，一是基于 WIMP (Window, Icon, Menu, Pointer) 的图形化界面，二是早期提供图形界面接口的机器缺乏代码级别之外的组件管理方式 (比如 Unix 的进程和 IPC)。
面向对象在 WIMP 的环境中是很必要也是很成功的。原因是 WIMP 环境需要重量的实现继承提供的重用，WIMP 的对象种类能很好的被单继承模拟，WIMP 的属性和类别容易区分。而面向对象扩展到 WIMP 之外的环境中就失败了：实际世界是多纬度的，属性和类别不好区分。红苹果是 color 属性为 red 的苹果，还是 Apple 的子类？实际世界的工具是用来完成任务的。而不是象 WIMP 那样构建一个虚拟的空间化界面。《人月神话》指出，编写 reusable code 比编写普通 code 至少要多花三倍的工作量。而面向对象的模糊了代码的重用和使用。使被重用的代码的依赖复杂化。导致很多不适合被重用的代码被重用。编写代码时要过分考虑重用的可能性。其它管理复杂度的机制越来越流行。
【知乎用户的回答(70票)】:
弊端是，没有人还记得面向对象原本要解决的问题是什么。
1、面向对象原本要解决什么（或者说有什么优良特性）
似乎很简单，但实际又很不简单：面向对象三要素封装、继承、多态
（警告：事实上，从业界如此总结出这面向对象三要素的一刹那开始，就已经开始犯错了！）。
封装：封装的意义，在于明确标识出会访问某个数据结构（用面向对象的术语来说就是 类成员变量）的所有接口。
有了封装，就可以明确区分内外，使得类实现者可以修改封装内的东西而不影响外部调用者；而外部调用者也可以知道自己不可以碰哪里。这就提供一个良好的合作基础——或者说，只要接口这个基础约定不变，则代码改变不足为虑。
继承+多态：继承和多态必须一起说。一旦割裂，就说明理解上已经误入歧途了。
先说继承：继承同时具有两种含义：其一是继承基类的方法，并做出自己的扩展——号称解决了代码重用问题；其二是声明某个子类兼容于某基类（或者说，接口上完全兼容于基类），外部调用者可无需关注其差别。
再说多态：基于对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同。
很显然，多态实际上是依附于继承的第二种含义的。让它与封装、继承这两个概念并列，是不符合逻辑的。不假思索的就把它们当作可并列概念使用的人，显然是从一开始就被误导了。
实践中，继承的第一种含义（实现继承）意义并不很大，甚至常常是有害的。因为它使得子类与基类出现强耦合。
继承的第二种含义非常重要。它又叫“接口继承”。
接口继承实质上是要求“做出一个良好的抽象，这个抽象规定了一个兼容接口，使得外部调用者无需关心具体细节，可一视同仁的处理继承自同一个基类的对象”——这在程序设计上，叫做归一化。
归一化使得外部使用者可以简单的用一个for循环，不加区分的处理所有接口兼容的对象集合——就好象linux的泛文件概念一样，所有东西都可以当文件处理，不必关心它是内存、磁盘、网络还是屏幕（当然，如果你需要，当然也可以区分出“字符设备”和“块设备”，然后做出针对性的设计：细致到什么程度，视需求而定）。
归一化的实例：
a、一切对象都可以序列化/toString
b、一切UI对象都是个window，都可以响应窗口事件。
——必须注意，是一切（符合xx条件的）对象皆可以做什么，而不是“一切皆对象”。后者毫无意义。
总结：面向对象的好处实际就这么两点。
一是通过封装明确定义了何谓接口、何谓接口内部实现、何谓接口的外部调用者，使得大家各司其职，不得越界；
二是通过继承+多态这种内置机制，在语言的层面支持归一化的设计，并使得内行可以从代码本身看到这个设计——但，注意仅仅只是支持归一化的设计。不懂如何做出这种设计的外行仍然不可能从瞎胡闹的设计中得到任何好处。
显然，不用面向对象语言、不用class，一样可以做归一化的设计（如老掉牙的泛文件概念、游戏行业的一切皆精灵），一样可以封装（通过定义模块和接口），只是用面向对象语言可以直接用语言元素显式声明这些而已；
而用了面向对象语言，满篇都是class，并不等于就有了归一化的设计。甚至，因为被这些花哨的东西迷惑，反而更加不知道什么才是设计。
2、人们以为面向对象是什么、以及因此制造出的悲剧以及闹剧
误解一、面向对象语言支持用语言元素直接声明封装性和接口兼容性，所以用面向对象语言写出来的东西一定更清晰、易懂。
事实上，既然class意味着声明了封装、继承意味着声明了接口兼容，那么错误的类设计显然就是错误的声明、盲目定义的类就是无意义的喋喋不休。而错误的声明比没有声明更糟；通篇毫无意义的喋喋不休还不如错误的声明。
除非你真正做出了漂亮的设计，然后用面向对象的语法把这个设计声明出来——仅仅声明真正有设计、真正需要人们注意的地方，而不是到处瞎叫唤——否则不可能得到任何好处。
一切皆对象实质上是在鼓励堆砌毫无意义的喋喋不休。大部分人——注意，不是个别人——甚至被这种无意义的喋喋不休搞出了神经质，以至于非要在喋喋不休中找出意义：没错，我说的就是设计模式驱动，以及。
误解二、面向对象三要素是封装、继承、多态，所以只要是面向对象语言写的程序，就一定“继承”了语言的这三个优良特性。
事实上，如前所述，封装、继承、多态只是语言层面对良好设计的支持，并不能导向良好的设计。
如果你的设计做不出真正的封装性、不懂得何谓归一化，那它用什么写出来都是垃圾。
误解三、把软件写成面向对象的至少是无害的。
要了解事实上是什么，需要先科普几个概念。
什么是真正的封装？
——回答我，封装是不是等于“把不想让别人看到、以后可能修改的东西用private隐藏起来”？
显然不是。
如果功能得不到满足、或者未曾预料到真正发生的需求变更，那么你怎么把一个成员变量/函数放到private里面的，将来就必须怎么把它挪出来。
你越瞎搞，越去搞某些华而不实的“灵活性”——比如某种设计模式——真正的需求来临时，你要动的地方就越多。
真正的封装是，经过深入的思考，做出良好的抽象，给出“完整且最小”的接口，并使得内部细节可以对外透明（注意：对外透明的意思是，外部调用者完全意识不到细节的存在）。
一个设计，只有达到了这个高度，才能真正做到所谓的“封装性”，才能真正杜绝对内部细节的访问。
否则，生硬放进private里面的东西，最后还得生硬的被拖出来——当然，这种东西经常会被美化成“访问函数”之类渣渣（不是说访问函数是渣渣，而是说因为设计不良、不得不以访问函数之类玩意儿在封装上到处挖洞洞这种行为是渣渣）。
接口继承真正的好处是什么？是用了继承就显得比较高大上吗？
显然不是。
接口继承没有任何好处。它只是声明某些对象在某些场景下，可以用归一化的方式处理而已。
换句话说，如果不存在“需要不加区分的处理类似的一系列对象”的场合，那么继承不过是在装X罢了。
封装可应付需求变更、归一化可简化（类的使用者的）设计：以上，就是面向对象最最基本的好处。
——其它一切，都不过是在这两个基础上的衍生而已。
换言之，如果得不到这两个基本好处，那么也就没有任何衍生好处——应付需求变更/简化设计并不是打打嘴炮就能做到的。
了解了如上两点，那么，很显然：
1、如果你没有做出好的抽象、甚至完全不知道需要做好的抽象就忙着去“封装”，那么你只是在“封”和“装”而已。
这种“封”和“装”的行为只会制造累赘和虚假的承诺；这些累赘以及必然会变卦的承诺，必然会为未来的维护带来更多的麻烦，甚至拖垮整个项目。
正是这种累赘和虚假的承诺的拖累，而不是所谓的为了应付“需求改变”所必需的“灵活性”，才是大多数面向对象项目代码量暴增的元凶。
2、没有真正的抓到一类事物（在当前应用场景下）的根本，就去设计继承结构，是必不会有所得的。
不仅如此，请注意我强调了在当前应用场景下。
这是因为，分类是一个极其主观的东西，不存在普适的分类法。
举例来说，我要研究种族歧视，那么必然以肤色分类；换到法医学，那就按死因分类；生物学呢，则搞门科目属种……
想象下，需求是“时尚女装”，你却按“窒息死亡/溺水死亡/中毒死亡之体征”来了个分类……你说后面这软件还能写吗？
类似的，我遇到过写游戏的却去纠结“武器装备该不该从游戏角色继承”的神人。你觉得呢？
事实上，游戏界真正的抽象方法之一是：一切都是个有位置能感受时间流逝的精灵；而某个“感受到时间流逝显示不同图片的对象”，其实就是游戏主角；而“当收到碰撞事件时，改变主角下一轮显示的图片组的”，就是游戏逻辑。
看看它和“武器装备该不该从游戏角色继承”能差多远。想想到得后来，以游戏角色为基类的方案会变成什么样子？为什么会这样？
——你还敢说面向对象无害吗？
——在真正明白何谓封装、何谓归一化之前，每一次写下class，就在错误的道路上又多走了一步。
——设计真正需要关注的核心其实很简单，就是封装和归一化。一个项目开始的时候，“class”写的越早，就离这个核心越远。
——过去鼓吹的各种面向对象方法论、甚至某些语言本身，恰恰正是在怂恿甚至逼迫开发者尽可能早、尽可能多的写class。
误解四、只有面向对象语言写的程序才是面向对象的。
事实上，unix系统提出泛文件概念时，面向对象语言根本就不存在；游戏界的精灵这个基础抽象，最初是用C甚至汇编写的；……。
面向对象其实是汲取以上各种成功设计的经验才提出来的。
所以，面向对象的设计，不必非要c++/java之类支持面向对象的语言才能实现；它们不过是在你做出了面向对象的设计之后，能让你写得更惬意一些罢了——但，如果一个项目无需或无法做出面向对象的设计，某些面向对象语言反而会让你很难受。
用面向对象语言写程序，和一个程序的设计是面向对象的，两者是八杆子打不着的两码事。纯C写的linux kernel事实上比c++/java之类语言搞出来的大多数项目更加面向对象——只是绝大部分人都自以为自己到处瞎写class的面条代码才是面向对象的正统、而死脑筋的linus搞的泛文件抽象不过是过程式思维搞出来的老古董。
——这个误解之深，甚至达到连wiki词条里面，都把OOP定义为“用支持面向对象的语言写程序”的程度。
——恐怕这也是没有人说泛文件设计思想是个骗局、而面向对象却被业界大牛们严厉抨击的根本原因了：真正的封装、归一化精髓被抛弃，浮于表面的、喋喋不休的class/设计模式却成了”正统“！
借用楼下PeytonCai朋友的链接：
————————————————————————————
总结： 面向对象其实是对过去成功的设计经验的总结。但那些成功的设计，不是因为用了封装/归一化而成功，而是切合自己面对的问题，给出了恰到好处的设计。
让一个初学者知道自己应该向封装/归一化这个方向前进，是好的；用一个面向对象的条条框框把他们框在里面、甚至使得他们以为写下class是完全无需思索的、真正应该追求的是设计模式，则是罪恶的。
事实上，class写的越随意，才越需要设计模式；就着错误的实现写得越多、特性用得越多，它就越发的死板，以至于必须更加多得多的特性、模式、甚至语法hack，才能勉强完成需求。
只有经过真正的深思熟虑，才有可能做到KISS。
到处鼓噪的面向对象编程的最大弊端，是把软件设计工作偷换概念，变成了“就着class及相关教条瞎胡闹，不管有没有好处先插一杠子”，甚至使得人们忘记去关注“抽象是否真正简化了面对的问题”。
【知乎用户的回答(13票)】:
我不知道为啥有人邀请我回答这个问题。不管怎么样我就来答一下
面向对象最大的问题是，这个词早就变成buzzword了。各种语言都大谈面向对象的优点，说自己支持面向对象，(所以就自动有这些优点)，而没人愿意去了解，到底什么才是面向对象。
面向对象的核心是消息。对象就好比是计算机，消息就好比是IP包。封装就是说，一个对象只有通过发消息才能改变另一个对象的状态。多态就是说，一个对象不关心另一个对象是怎么工作的，只要遵守相同的协议，就能协作。一种语言要是要求把函数调用脑补成消息的那一定不是面向对象的。但是很不幸，很多自以为是面向对象的语言，把函数调用称为发消息， 把一组约定好参数格式的函数称为协议，把名词的含义都搞乱了，实际上，这种做法更接近于Abstract Data Type而不是面向对象。这就是现代的指鹿为马。
所以，你会看到很多人会抱怨Erlang不支持面向对象，而且，Erlang最初的作者们也很讨厌面向对象，实际上呢，在常见的语言里，还真的只有Erlang是面向对象的。
你看看Erlang就会知道，对于面向对象来说，类并没有那么重要，当然了，继承也没有什么大问题。这些开销都是因为冒牌的面向对象语言不原生支持消息导致的，而不是类，或者面向对象导致的。
你能看见Erlang就因为两点，一是，爱立信当年一个项目用C++，延期了很久也没开发出来，没办法就拿Erlang试试，结果就有了那个AXD301。非要说的话，那也是面向对象提高了开发效率。二是，爱立信当时脑残了，尽管内部研究已经得出结论说Erlang开发效率就是高，但还是因为Erlang是私有语言，禁止在新项目中使用Erlang。Erlang的开发者们不接受这种说法，就去推动Erlang开源。
现在根本就是不是谈面向对象弊端的时候，等Erlang流行起来再来谈还差不多。
【kubisoft的回答(12票)】:
大部分问题是面向对象无法解决的。能够采用面向对象简化模型得到代码重用性的时候，就用；不能的时候，就放弃，不要到处都用。
有的场合下，面向对象会增加代码复杂度，增加维护的困难。
除了面向对象，我们还有很多办法来实现我们要做的功能。不谈更加高端大气的函数式编程，其实用一串switch case或者else if就可以实现，代码还简单。
所有需要的东西都放在一起，同一个文件里面同一段代码，阅读起来并不困难，很整齐。某个case下面太长的时候，也可以独立出来包装成一个函数调用；你爱放在同一个文件里面还是另开一个文件都可以。
可是面向对象是一个很重量级的方法。你得设计类的继承关系。得写类的声明，得实现不同的虚方法；实现时要注意是否要调用父类的方法。调试的时候经常搞不清楚到底执行哪个类的虚方法了。而用一大堆switch case，语句执行顺序一目了然。
可能还是觉得代码层级过多？有很多办法可以整理得更干净。用了面向对象，省了switch case，却要写更多的virtual function的声明和实现。
业务逻辑本身是复杂的，无法避免。没有银弹。
【知乎用户的回答(14票)】:
很多时候为了OO而OO就是它最大的弊端。
【vczh的回答(17票)】:
你怎么会觉得类关系的设计会成为一个开销呢？其实正因为你有这种感觉，所以你才不能参加大型软件的开发的。开发一个软件比这个复杂的东西多了去了，连几个类的关系你都会觉得很麻烦，那逻辑根本不要处理了。
当然，我并不是说OO就是万能的，他当然在某些领域里面有坏处，但是坏处也不是在你想象中的什么
【类关系的开销】上的。但是一个东西要不要用OO做，基本上得看你老板喜欢什么语言。就算他做个UI framework想用haskell，你也得上了。
【知乎用户的回答(8票)】:
作为C原教旨教徒和C＋+一生黑以及从不用类的Python党怒答。有函数有数据结构就可以了，面向对象就是个骗局………
【不知秋的回答(3票)】:
面向对象只是一种组织逻辑的方式，类关系复杂说明逻辑没划分清楚。
【知乎用户的回答(5票)】:
不忘初心，方得始终。
前面几个答案都说到了点子上：OOP最大的弊端，就是很多程序员已经忘记了OOP的初心，潜意识中把OOP教条主义化（如同对GOTO语句的禁忌一般），而不是着眼于OOP着力达到的、更本质的目标，如：
- 改善可读性
- 提升重用性
但是OOP最重要的目标，其实是OCP，即「」。这一点很多答案都没有提到。
遵循开闭原则设计出的模块具有两个主要特征：
（1）对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。
（2）对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。
这就是为什么会有「用多态代替switch」的说法。在应该使用多态的地方使用switch，会导致：
1 - 违反「开放扩展」原则。假如别人的switch调用了你的代码，你的代码要扩展，就必须在别人的代码里，人工找出每一个调用你代码的switch，然后把你新的case加进去。
2 - 违反「封闭修改」原则。这是说，被switch调用的逻辑可能会因为过于紧密的耦合，而无法在不碰switch的情况下进行修改。
但是OCP不是免费的。如果一个模块根本没有扩展的需求，没有多人协作的需求，花时间达成OCP又有什么意义呢？设计类关系的时候忘记了OOP的初心，可能就会写出很多没有帮助的类，白白浪费人力和运行效率。
所以，假如所有代码都是你一个人维护，没有什么扩展的需求，那么多用一些switch也未尝不可；假如你的代码是要被别人使用或者使用了别人的代码，OOP很可能就是你需要用到的工具。
除了OOP，Type class和Duck Typing都是可以帮助你达成OCP原则的工具。当然，如果你使用的语言是Java，这两种工具都不用想了。
【PeytonCai的回答(4票)】:
我觉得只有封装和接口才是软件设计的精髓，这也应该是为什么GO语言了只实现了接口这个特性。
【薛非的回答(2票)】:
我觉得也许问题应该是面向对象编程的局限是什么为好吧面向对象编程并不适用所有情况
在不适用的情况下硬要面向对象编程必然有问题
但把这归结为弊端也许不太公平
【姜兆宁的回答(6票)】:
容易走神，背对对象会好很多
【童刚刚的回答(1票)】:
面向对象和面向过程只是代码的组织方法不同，代码本身还是那些代码，并没有减少。
但是面向对象和面向过程最关键的还是思想，你做题目的时候总是先从大局出发，而面向过程却要求你先写最小的单元。
要你算一下1+2等于几，用面向过程肯定最简单，要是写个现实的程序就困难了。
【郭小灿的回答(0票)】:
没有关系设计开销其实很可能花更多时间在复杂逻辑的编写上而且很有可能不容易维护
,目前来说面向对象还是构建易维护软件的比较理想的形式
另外就编写逻辑层来说确实写起来相比于函数式编程会比较慢
【张鑫的回答(0票)】:
面向对象是一个非常基础的概念，题主想质疑的可能是面向对象中的过度使用的抽象设计。还有一些语言的面向对象是无类型的，比如JavaScript，题主可以多了解一下。
【JaskeyLam的回答(0票)】:
增加了设计上的难度。
【殷奎生的回答(0票)】:
我认为面向对象是个过渡概念，有它的历史价值。由面向对象到基于接口的组件编程，是个巨大进步。解决了大规模软件组织的困难。不过因为面向对象是有状态的，在cpu多核成为主流的今天，有状态成为发挥多核效能的最大的 困难（同步、锁，不好整）。所以函数式编程又咸鱼翻身了。
【qwetyed的回答(0票)】:
面向对象得目标是大规模重用代码。
面向对象的手段是绑定结构和函数。
面向对象的哲学含义是给客体下定义来完成形式化抽象。 目的说白了就是为了尽可能重用代码来减少程序员工作。但是矛盾的地方在于，真实世界中的客体的定义随着主体的看法而改变，换句话，不存在固定的形式化抽象，一切都要符合环境（上下文）。最简单的例子就是，中文词的含义天天变，只有根据环境知识才能知道是什么含义。
而代码是为了具体问题而出现的，所以不存在通用抽象，也就不存在可以无限重用的定义和逻辑。
所以对象也就是用于计算的模型而已，技术手段是正确的（给数据绑定操作） 但是对于目标（大规模代码重用）相去甚远，能重用的应该只有为了解决问题的方法，而不是只有模型。
另外的难点，不同人为了解决相似问题，开发出来的模型可以十万八千里，为了重用模型，修改之后又能适应新问题，于是这叫泛化，它估计你去制造全能模型，但是不仅难，还没法向后兼容，有时候就硬是要把飞机做成鱼……这就是面向对象思维的硬伤，创造出一个大家都懂，大家都认为对，大家都能拿去用的模型太难！
更加合理的设计理念应该还是 提供机制而不限制策略 所以从这一点上来看，提供一个常用的函数库要比精心设计复杂的对象模型要好的多。
更进一步，理想状态是全世界共享一种函数式语言，共享一份源代码，并对问题分类，将所用所有函数按照问题进行整理，只有这样感觉才能彻底避免重新发明轮子。
【刘十九的回答(0票)】:
前段时间读到一篇文章《名词王国的死刑》
这是一种信仰，拿着锤子，把世界当成钉子。
当一个新的想法出现在你脑海的时候，你不得不重塑它，包装它，甚至弄碎它，直到它变成一个名词，即使它一开始是一个动作，过程，或者任何不是"物"的概念。
我没有黑面相对象的意思，相反我很喜欢这个编程范式，只是没有什么东西是完美的，如果用面相对象表达一些东西很别扭的时候，我们不必总是去妥协我们的思维，也许我们还可以试试函数式，或许就柳暗花明了呢
【宋锐的回答(0票)】:
OO 最有用的地方：将可能改变的地方，变量化。
&&&&&本文固定链接:
【上一篇】
【下一篇】
您可能还会对这些文章感兴趣！
最新日志热评日志随机日志