下载文档原格式
面向对象和面向过程的例子面向对象和面向过程是计算机编程中的两种不同的编程范式。
这两种范式在软件开发过程中具有不同的思维方式和设计理念。
本文将以生活中的一个例子来讲解面向对象和面向过程的概念，并分析它们的优缺点及适用场景。
假设我们要设计一个汽车出租系统来管理汽车出租的业务流程。
首先，我们来看一下面向过程的设计思路。
在面向过程的设计中，我们将整个业务流程分解为不同的步骤，每个步骤都需要具体的操作和处理过程。
首先，我们需要定义一个函数来处理客户租车的请求，这个函数需要接收客户的信息，并判断是否满足租车的条件。
如果满足条件，接下来我们需要调用一个函数来计算租车的费用，然后再调用一个函数来更新租车系统的数据库。
最后，我们需要输出客户的租车信息。
这种面向过程的设计思路在实现上比较直接和简单。
每个函数都有明确的输入和输出，易于进行单元测试和调试。
然而，随着业务流程变得复杂，面向过程的设计容易产生大量的函数调用和多层嵌套，不利于代码的维护和扩展。
而且，由于函数之间直接共享数据，可能导致数据的冗余和不一致。
因此，当业务流程比较简单且变化较小时，面向过程的设计思路是比较合适的。
接下来，我们来看一下面向对象的设计思路。
在面向对象的设计中，我们将汽车出租系统抽象为几个对象：客户、汽车和租车系统。
每个对象都有自己的属性和方法。
客户对象有姓名、联系方式等属性，还有租车的方法；汽车对象有车牌号、品牌等属性，还有计算租金的方法；租车系统对象有客户列表、汽车列表等属性，还有处理租车请求的方法。
这种面向对象的设计思路更加符合现实世界的模型，易于理解和沟通。
对象之间的关系和交互通过方法的调用来实现。
每个对象都有自己的状态和行为，能够更好地封装和隐藏数据。
这样一来，当业务流程变得复杂且需要扩展时，我们可以更加方便地添加新的对象和方法，而不需要修改已有的代码。
因此，面向对象的设计思路适合于大型和复杂的系统开发。
通过以上对比，我们可以看出面向对象和面向过程的设计思路各有优劣，适用于不同的场景。
案例“图书管理系统”面向对象分析与设计例如，“图书管理系统”面向对象分析与设计大致过程如下：1.需求调查分析需求调查分析的结果一般用文字描述，必要时也可用业务流程图辅助描述。
“图书管理系统”需求陈述如下：在图书管理系统中，管理员要为每个读者建立借阅账户，并給读者发放不同类别的借阅卡（借阅卡可提供卡号、读者姓名），账户内存储读者的个人信息和借阅记录信息。
持有借阅卡的读者可以通过管理员（作为读者的代理人与系统交互）借阅、归还图书，不同类别的读者可借阅图书的范围、数量和期限不同，可通过互联网或图书馆内查询终端查询图书信息和个人借阅情况，以及续借图书（系统审核符合续借条件）。
借阅图书时，先输入读者的借阅卡号，系统验证借阅卡的有效性和读者是否可继续借阅图书，无效则提示其原因，有效则显示读者的基本信息（包括照片），供管理员人工核对。
然后输入要借阅的书号，系统查阅图书信息数据库，显示图书的基本信息，供管理员人工核对。
最后提交借阅请求，若被系统接受则存储借阅纪录，并修改可借阅图书的数量。
归还图书时，输入读者借阅卡号和图书号（或丢失标记号），系统验证是否有此借阅纪录以及是否超期借阅，无则提示，有则显示读者和图书的基本信息供管理员人工审核。
如果有超期借阅或丢失情况，先转入过期罚款或图书丢失处理。
然后提交还书请求，系统接受后删除借阅纪录，并登记并修改可借阅图书的数量。
图书管理员定期或不定期对图书信息进行入库、修改、删除等图书信息管理以及注销（不外借），包括图书类别和出版社管理。
2. 用况健模（1）确定执行者通过对系统需求陈述的分析，可以确定系统有两个执行者：管理员和读者。
简要描述如下：1)管理员：管理员按系统授权维护和使用系统不同功能，可以创建、修改、删除读者信息和图书信息即读者管理和图书管理，借阅、归还图书以及罚款等即借阅管理。
2)读者：通过互联网或图书馆查询终端，查询图书信息和个人借阅信息，还可以在符合续借的条件下自己办理续借图书。
面向对象典型案例
面向对象编程是一种编程方法论，它的核心思想是将现实世界中的事物抽象成对象，通过对象之间的交互来实现程序的功能。
下面我们来介绍一些典型的面向对象案例。
1. 银行账户管理系统
银行账户管理系统是面向对象编程的典型案例之一。
在这个系统中，每个账户都是一个对象，它有自己的属性（如账号、余额、户主姓名等）和方法（如存款、取款、查询余额等）。
通过对象之间的交互，可以实现账户的管理和操作。
2. 游戏开发
游戏开发也是面向对象编程的一个重要应用领域。
在游戏中，每个角色、道具、场景等都可以抽象成一个对象。
通过对象之间的交互，可以实现游戏的运行和交互。
3. 汽车租赁系统
汽车租赁系统也是一个典型的面向对象案例。
在这个系统中，每辆汽车都是一个对象，它有自己的属性（如车型、租金、出租状态等）和方法（如租车、还车、查询车辆列表等）。
通过对象之间的交互，可以实现汽车租赁的管理和操作。
4. 医院管理系统
医院管理系统也是一个常见的面向对象案例。
在这个系统中，每个病人、医生、药品等都可以抽象成一个对象。
通过对象之间的交互，可以实现医院的管理和操作，如病人挂号、医生诊断、药品配药等。
总结：面向对象编程是一种非常实用的编程范式，它可以提高程序的可维护性、可扩展性和可重用性。
以上介绍的典型案例只是冰山一角，面向对象编程在各个领域都有着广泛的应用。
Java面向对象编程实战案例1. 简介Java面向对象编程（Object-Oriented Programming，OOP）是一种常用的编程范式，它以对象为中心，通过封装、继承和多态等特性来组织和管理代码。
本文将介绍一些实战案例，展示Java面向对象编程的实际应用。
2. 案例一：学生管理系统学生管理系统是一个典型的Java面向对象编程案例，它常用于学校、培训机构等管理学生信息。
在这个案例中，可以定义一个Student类，包含学生的姓名、年龄、学号等属性，以及学生的增删改查等方法。
可以使用面向对象的思想，将学生信息封装到一个对象中，并使用集合类来管理多个学生对象。
3. 案例二：图形计算器图形计算器是另一个有趣的Java面向对象编程案例。
可以定义一个Shape类作为图形的基类，包含计算图形面积和周长的方法，并派生出Circle、Rectangle和Triangle等子类，分别表示圆形、长方形和三角形。
通过面向对象的继承特性，可以调用对应子类的计算方法，根据用户的输入来计算所需图形的面积和周长。
4. 案例三：银行账户管理系统银行账户管理系统是一个常见的Java面向对象编程案例，用于管理银行的账户信息。
可以定义一个Account类，包含账户的姓名、余额、存取款等方法，并通过封装特性将账户信息隐藏在对象中。
可以使用ArrayList类来存储多个账户对象，实现对账户信息的管理和操作。
5. 案例四：图书馆管理系统图书馆管理系统是另一个典型的Java面向对象编程案例，用于管理图书馆的图书信息。
可以定义一个Book类，包含图书的书名、作者、价格等属性，并封装对应的get和set方法。
可以使用HashMap类来存储图书编号和对应的图书对象，实现图书的检索和借还功能。
还可以定义一个User类表示图书馆的用户，包含用户的姓名、借书数量等属性。
6. 案例五：游戏角色管理系统游戏角色管理系统是一个有趣的Java面向对象编程案例，用于管理游戏中的角色信息。
例：超市进销存系统的需求描述如下： （1）销售①售货员接收顾客订购，输入顾客购买的商品，计算总价； ②顾客付款并接收清单；③售货员保存顾客购买商品的记录清单。
（2）库存①库存管理员每天进行盘点一次；②库存管理员当发现库存商品有损坏时，及时到相关部门报损； ③在供应商的商品到货时，库存管理员首先检查商品是否合格，并将合格的商品入库处理；当商品进入卖场时，进行商品出库处理；④经理、订货员根据需要进行库存商品的模糊查询或详细查询。
（3）订货①订货员用新商品供应商信息更新供应商数据库的信息； ②订货员统计库存商品是否低于库存下限，然后制作订货单。
（4）统计①经理能够使用系统的统计功能，了解商品销售情况、库存情况、供应商情况，以便进行合理的营销策略。
②经理按市场情况适时变动商品价格。
试建立超市进销存系统的用例模型。
顾客图1 销售子系统商品出入库图2 库存子系统制作订货单图3 订货子系统用例模型特殊商品查询图4 统计子系统用例模型思考？？在用例图中的用例通常只是简单地给出了系统应提供什么服务，并没有展示出如何提供服务，如服务的具体功能、处理流程、场景、出错情况以及异常情况等信息，如何能知道前述信息？！！！用例的描述常采用文字列表形式，也可采用UML图形描述，如交互图、活动图等。
3.试为以下各类建立UML类图及描述它们间的关系。
家用电器、电视机、液晶电视机、电视遥控器、DVD播放机、组合音响、音响功放、音箱、喇叭、低音泡、高音泡、厨具、电厨具、微波炉、电磁炉、电饭煲销售管理子系统的部分用例描述：订货管理子系统的部分用例描述：库存管理子系统的部分用例描述：网络教学系统的需求分析一、系统的功能需求：（１）学生可以登录网站浏览信息，查找信息和下载文件。
（２）老师可以登录网站输入课程简介，上传课件文件，发布消息，修改和更新消息（３）管理员可以对页面进行维护以及批准用户的注册申请。
二、功能模块划划分：满足上述需求的系统主要包括以下几个模块：（１）数据库管理模块。
面向对象案例在面向对象的编程中，我们经常会遇到各种不同的案例，这些案例涉及到了对象、类、继承、多态等概念的应用。
下面，我将通过几个具体的案例来说明面向对象编程的应用。
案例一，图书管理系统。
假设我们需要设计一个图书管理系统，这个系统需要包括图书的借阅、归还、查询等功能。
在面向对象的设计中，我们可以将图书、读者、图书管理员等抽象成对象，然后通过类来描述它们的属性和行为。
比如，我们可以设计一个Book类来表示图书，包括书名、作者、出版社等属性，以及借阅、归还等行为；再设计一个Reader类来表示读者，包括姓名、借阅的图书等属性，以及借阅、归还等行为；还可以设计一个Librarian类来表示图书管理员，包括姓名、管理的图书等属性，以及借阅、归还等行为。
通过这样的设计，我们可以很好地模拟出一个图书管理系统，并且可以方便地对其进行扩展和维护。
案例二，银行账户管理系统。
另一个常见的案例是银行账户管理系统。
在这个系统中，我们需要对账户进行存款、取款、查询等操作。
同样地，我们可以将账户、客户、银行职员等抽象成对象，然后通过类来描述它们的属性和行为。
比如，我们可以设计一个Account类来表示账户，包括账号、余额等属性，以及存款、取款等行为；再设计一个Customer类来表示客户，包括姓名、账户等属性，以及存款、取款等行为；还可以设计一个Banker类来表示银行职员，包括姓名、管理的账户等属性，以及存款、取款等行为。
通过这样的设计，我们可以很好地模拟出一个银行账户管理系统，并且可以方便地对其进行扩展和维护。
案例三，汽车租赁系统。
最后，我们来看一个汽车租赁系统的案例。
在这个系统中，我们需要对汽车进行租赁、归还、查询等操作。
同样地，我们可以将汽车、租户、租赁员等抽象成对象，然后通过类来描述它们的属性和行为。
比如，我们可以设计一个Car类来表示汽车，包括车牌号、品牌、型号等属性，以及租赁、归还等行为；再设计一个Tenant类来表示租户，包括姓名、租赁的汽车等属性，以及租赁、归还等行为；还可以设计一个RentalAgent类来表示租赁员，包括姓名、管理的汽车等属性，以及租赁、归还等行为。
面向对象程序设计的实践案例分析面向对象程序设计是一种常用的编程范式，其主要概念包括封装、继承和多态。
在实际编程中，使用面向对象程序设计可以使代码结构清晰、易于维护和扩展。
本文将以几个实际案例为例，探讨如何运用面向对象程序设计来实现复杂的系统。
案例一：学生信息管理系统假设有一个学生信息管理系统，需要记录每个学生的姓名、学号、性别、年龄、班级等信息，并且支持添加、删除、修改、查询学生信息的功能。
我们可以使用面向对象程序设计来实现该系统。
首先，我们可以定义一个名为Student的类来表示每个学生。
该类包括以下属性：姓名、学号、性别、年龄、班级等。
同时，该类还需要支持一些操作，如添加、删除、修改、查询等。
接下来，我们可以定义一个名为StudentManager的类来管理所有学生信息。
该类包括以下操作：添加学生、删除学生、修改学生信息、查询学生信息等。
同时，该类需要维护一个学生列表来存储所有学生信息。
最后，我们可以定义一个名为Main的类来实现系统的主要功能。
该类包括以下操作：显示菜单、获取用户输入、执行指定操作等。
通过Main类，用户可以选择要执行的操作，例如添加学生、删除学生等。
在执行指定操作之后，Main类将调用StudentManager类的相应方法来完成该操作。
以上是一个简单的学生信息管理系统，通过面向对象程序设计，我们可以将系统功能模块化，使得代码清晰易懂、易于维护。
案例二：银行账户管理系统假设有一个银行账户管理系统，需要记录每个账户的账号、余额、利率等信息，并且支持存款、取款、查询余额等功能。
我们可以使用面向对象程序设计来实现该系统。
首先，我们可以定义一个名为Account的类来表示每个账户。
该类包括以下属性：账号、余额、利率等。
同时，该类还需要支持一些操作，如存款、取款、查询余额等。
接下来，我们可以定义一个名为AccountManager的类来管理所有账户信息。
该类包括以下操作：添加账户、删除账户、查询账户信息等。
基于UML的面向对象分析与设计案例摘要本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。
本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。
本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮助朋友们更好的认识UML在OOA&D中起的作用。
前言经常听到有朋友抱怨，说学了UML不知该怎么用，或者画了UML却觉得没什么作用。
其实，就UML本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。
另外，UML也可以看做是OO思想的一种表现形式，可以说“OO是神，而UML是型”。
所以，想用好UML，扎实的OO思想基础是必不可少的。
然而，在UML应用到开发过程中时，还是有一定的模式可以遵循的。
（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。
）下面，我们通过一个CMS系统的分析设计实例，看看如何将UML应用到实际的开发中。
1.从需求到业务用例图OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。
我们的CMS系统需求非常简单，大致课做如下描述：这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。
任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。
管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。
通过以上需求描述，我们画出如下的业务用例图：这里要注意三点：1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。
它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。
例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录”的。
2.业务用例仅包含客户“感兴趣”的内容。
3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。
一个完整的面向对象分析与设计例子首先说明,接下来这部分内容,跟面向对象没什么关系,只是描述出我们接下来"需要做什么".大家都知道电梯是怎么回事了,所以获取需求的过程我就不啰嗦了,直接把最后结果描述出来.(对于计算机专业学生或软件工程毕业设计的需求分析结果应该有些参考意义...起码可以看出怎么样的结果才真正有意义)电梯楼层1-10 楼(也就是没有什么地下室也没有中间跳过某些楼层,最普通的情况),一共有2部电梯.如果一个在n楼(1 <n <10)的乘客按了下行按钮,那么下一个正在向下走的电梯到了n楼必须停下接收乘客.如果电梯里已经没有乘客了,电梯应该留在原位置直到再次投入使用.在将乘客送到目的地以前电梯不允许反向运动.(也就是电梯比如把乘客从9楼带到楼下,如果在走到4楼的时候5楼有人要下,电梯不能从4楼回5楼去,而要把乘客带到楼下再回来)满载的电梯不再收人.电梯里有个按钮面版,里面有10个楼层的按钮. 按下按钮表示该楼层变成一个目的地,按钮会发光,到达以后按钮不再发光.建筑物2-9楼层有一个按钮面版,上面两个按钮分别是向上和向下.1楼只有向上,10楼只有向下.电梯有一个控制中心来自动控制,不用人手干预. ...............(其他,略)第二部分到底上面的需求描述中,哪些东西可以成为我需要来"面向"的"对象"?首先,我们要选择出候选的对象,然后再在候选对象里选择真正为程序设计所使用的对象.候选对象的选择有很多方式,比方说"名词短语频率分析",对上面那段去分析看哪些名词出现次数很多,说明可能比较重要,可以直接拿来当候选对象. 比如楼层,电梯,按钮,乘客,都出现很多次. 当然还有另外的方式,比如"按方面建立" (PS: I 'm sorry,我是个实用主义者,只要目的达到了...我不喜欢像一些书本上那样用些概念糊弄人,上面红字的两个方法的名称是我临时取的.....也许不好听,也许他们有更优美的名字.....反正这不是我们该担心的,留给教材编写人员取操心吧...) 从人\组织\设备\物品\业务\事件\表格几个方面去找对象去.这里要注意的是对象的选择要看具体情况的,比如 .... 我们把"放飞希望" 作为一个具体的对象实例( ^_^ ), 如果在医疗系统中,可以抽象成"人" 这个类,由脑袋\身体\手\脚......等部分. 如果是在教育管理系统中, 就不能这么处理,可能要抽象成"老师" 这个类, 包括教学年限\工资\所教科目\..... 等内容.还有一点需要注意的是不要跨过系统边界. 系统之外的事情就不要管了,就说我们这个电梯调度, 电梯的生产日期啊什么的,还有乘客的姓名, 都根本雨系统无关,这些是不需要的.最后有一点被非常非常非常非常非常多的工程师们所忽视的就是建立面向对象分析模型的时候, 只应该考虑逻辑,而不要去考虑跟实现技术相关的东西. 比如按钮是塑料的还是金属的, (当然这个很明显是分外的事,大多数人在做调度分析的时候不会考虑这个,不过有些情况却很隐蔽..)现在回到我们具体问题,假设现在我们列出来的初步的清单是这样的(可能100个人有100个列法,不过没关系,这是正常的...): 电梯\电梯门\电梯位置\乘客\目的地按钮\大楼.....这离真正可以用的对象还差很多, 我们需要对每个词进行分析,看看到底是不是,值得不值得把这个当一个对象来考虑.我们分析从以下几个方面看:它在系统里有功能吗? (比如电梯天花板就该删除掉....如果有的话....)其他对象需要这个对象帮忙做点什么事吗? (比如乘客需要电梯把他带上去...)其他对象需要这个对象的数据吗?(比如控制中心明显需要知道电梯现在在哪..)这个对象是不是包含了有用却不对别的对象公开的内容.(比如电梯上面的吊链和发动机明显是有用的,不然电梯无法动也就无法调度了, 但是明显对于其他对象,都是不需要公开的, 不管是乘客还是控制中心都不需要控制电梯的马达---这里可能有人要有意见了, 控制中心不控制电梯马达么? 答案是不该控制,控制中心应该只告诉电梯你要向上还是向下还是停, 至于马达转多快怎么转,是电梯自己的电路来控制的才对, 责任分开明确有利于系统的维护.)这个对象有没有一个生存期,是不是描述了产生--各种运行状态--消亡的信息.比如一次电梯召唤-(谁想个好听点的名字? 呵呵....) 产生是用户按了向上或向下的按钮. 然后进入"电梯来" 这个状态, 再进入电梯停(包括开门,乘客进去,关门)的状态,然后又是"电梯走" 的状态,再之后是电梯再停给用户下去,然后这个电梯召唤以电梯停止移动等待下次召唤作为结束.如果向应用领域的专家(这里比如是电梯工程师)描述这个对象,他是否可以马上明白重要性? (比如如果你对一个电梯工程师说"调度工厂",他应该就不明白..因为工厂模式是面向对象设计的手段,跟电梯这个主题本身没多少联系)以上列出的6点,不一定要每点都符合,不过如果每点都不符合,那不用考虑...删掉吧........然后考虑系统以外的情况了. 这些对象中:系统能识别吗? (比如对于超重还是不超重...有些就可以识别,有些电梯就不能..)哪些是系统必须做出响应的(用户按的按钮明显就是一个...)对于发生的事件(比如按下按钮,比如电梯门打开) 哪些对象可以识别它?有没有没用上的?还需要其他对象吗?有没有不能识别又不需要响应的对象(比如用户的帽子???? ^_^) ,不过要注意,并不是绝对的,在极少数情况下,不能识别又不需要响应的对象是有用的.不过那是后话了,先不考虑它....系统需要跟其他系统相连么? (比如,跟火灾警报系统相连, 火灾发生时不准打开电梯门...这里当然我们不考虑这么复杂,但是毕竟是存在这样的东西)用于沟通两个对象的对象是不是不小心漏掉了? (这是常见的)在你删除一个候选对象的时候,问问: 去掉以后系统会怎样? 如果我要重用一个包含了这个对象的一大块功能,这个对象到底会给真的用上么?(注意重用是非常重要的,绝对不要为了一个地方而写程序,程序要可以在不同地方重用,就像不会有生产一个电视机的电视机厂一样)不断重复上面的过程,最终,你应该从不断增加新东西和不断删除东西后获得一个有些用的列表,假设如下面这样:到达事件: (就是表示电梯到了,包括开门,进电梯,关门..还有灯亮灯灭等一系列内容..)到达按钮面版(就是电梯里那10个按钮)电梯(这个没什么疑问了........)楼层...............................(其他略)然后要做的事情是给每个词一个文字描述,比如电梯的描述如下Elevator (类名一般请不要用中文.....虽然你要用中文也行....):执行电梯的控制(上走,下走)和报告功能(告诉控制中心现在自己在几楼..), 内部封装(就是不对外公开它是怎么做的,只公开结果)了控制电梯运行(马达怎么转..), 报告电梯位置,识别电梯是否准备就绪的各种服务. 他包括的属性是电梯的运动方向\位置\状态方面的信息.最后出来的对象不可能证明就是对的,也一般不会全错, ^_^ 人的问题.....注意最终用户也许会对这个有影响,所以最好还要问问他们,如果他们提出些比较麻烦的意见,如某种特定实现技术(比如如果电梯这个楼是一家生产音响的,也许老总有想法就要在电梯里有个音箱,电梯每到一层楼会报一次位置........-_- .....) 应该用专业角度劝他不要这样,如果他一定要.........那你也没办法了,谁让他是出钱的... ^_^这个模型可能会在后面被修改很多,做好心里准备.最后说一下命名, 对象的类名应该是个类而不是个功能.或一个属性. 比如可以叫"电梯" 却不好叫"电梯颜色"或"电梯上升". 对象类名最好全部都惟一,实在不好惟一了,就用不同的包分开,就像把相同文件名的不同文件放不同的文件夹里就行. 对象名称必须在应用领域有意义(也就是在这里必须在电梯界有意义, 而不能只在软件界有意义..) 用名词或形容词+名词, 不要用名词+动词的方式. 不要出现"和", "或", "与"之类的内容.(比如人就叫Humen 不要叫LadiesAndGentalmen.... ^_^ )现在,大家列出些什么对象了呢?ArrivalEventArrivalPanelDestinationEventDestinationPanelElevatorElevatorMotorFloorOverweightSensorSummonsEventSummonsPanel .......................................................大概是这样的一些东西,(可能跟我这个差十万八千里,不过没关系,那也是正常的.....如果照上面说的做了,那应该也错不到哪去..)好了,.....今天先到这,未完待续抛砖引玉, 思考面向对象是什么? (面向对象系列之二)上一个文章驳斥了别人误人子弟,不过深刻记得十几年前老师就教过, 如果你自己不能做得更好,就不要说别人不好.所以这篇聊聊跟面向对象有关系的话题,希望抛砖引玉.先考虑一个现实问题, 大家都熟悉的手机发短信. 来看看早期(A 大约是汇编语言时代),中期(B 结构化),现在(C 面向对象)三种思想下的不同实现.我说的是思想, 因为虽然现在大家使用着面向对象的工具,但是大部分程序员的思想依然没有面向对象. 比如现在我手下这群程序员里有面向对象分析和设计能力的也就一个..用最面向对象java和C#也可以写出杂乱无章完全不面向对象甚至不结构化的程序.注意到现在我们的手机号码分成移动和联通两种, 虽然对我们来说,不过是号码不一样收费不太一样,没多少区别,但是两家的短信接口可是完全不一样的.假设程序要求用户在界面上输入手机号码(TextBox1),输入一条短信内容(TextBox2),按确定(Button1),就可以把短信发到那个手机上A 一步一步走,该干什么就干什么...看看伪代码:st***号码= TextBox1.Text;st***内容= TextBox2.Text;int 第3位数字= int.Parse(号码.Substring(2,1)); //把第3位取出来,用来判断是不是移动的手机如1390000000 就取出一个9if(第3位数字> 3){............//这里是一堆长长的代码用来发送***的短信...省略,我们这里只说程序的思想..不涉及技术细节}else{..........//又是一堆长长的代码用来发送***的短信}B 写一个库,定义出发送***短信的函数和发送***短信的函数,还有判断的函数,假设函数原型分别是发送移动短信(st***手机号码,st***内容);发送联通短信(st***手机号码,st***内容);bool 是否是移动号码(st***手机号码);然后写程序如下:if(是否是移动号码(TextBox1.Text))发送移动短信(TextBox1.Text,TextBox2.Text);else发送联通短信(TextBox1.Text,TextBox2.Text);C 定义一个抽象接口"短信接收者", 由"*** "和"*** " 两个类分别实现接口. 各自实现发送短信方法.然后构造一个"手机工厂"(一时想不到好的名字,暂时叫这个吧) , 接收一个号码,返回一个"短信接收者"接口(里面根据接收的参数,可能是***或***)然后程序如下(一行..):手机工厂.获取接受者(TextBox1.Text).发送(TextBox2.Text);或写成这样清晰点:st***号码= TextBox1.Text;st***内容= TextBox2.Text;手机工厂.获取接受者(号码).发送(内容);OK,对于上面3段伪代码大家有什么想法? 第3种是不是看起来有点爽? 也许把,也仅仅是看起来那么一点爽,没什么大不了.没错,面向对象是在大型的地方更能体现优势,一小堆是展现不出来的. 我们假设程序中一共有100个这样的地方(比如一个是发短信的,一个接短信的,一个打电话的,一个上网的.....)那么对于A程序,很抱歉,非常要命,要在100个地方复制代码,复制100份,然后对其中99份做修改(或多或少,总要改点..)B程序只是在每个调用的地方加几行,可以接受.C程序在调用点也是加1行,同样也可以接受.这个时候,结构化和面向对象共同的优点体现出来了,复用性(教科书中讲面向对象总是说说复用是面向对象比其他方法的优势,其实结构化本身就是可复用的)A方法差不多该抛弃了........这就是结构化发展起来以后, 非结构化很快面临淘汰地步的原因,因为在软件稍微大点,就出麻烦,写写单片机小模块还行.软件在一天天变大变复杂,仅仅是变大变复杂而已? 当然不是. 也变得多变. 用户的需求时时在变.软件也容易变,.回到刚才的问题, 现在不是有小灵通么? 你又需要多一种类型,变成小灵通\移动\联通3种类型.那么对于 A ,灾难发生....修改程序的成本不比重新做一个少.对于B 需要去100个调用的地方多加一个if来判断,然后多加一个对应小灵通的函数. 修改量有点大,不过也不是不行,因为毕竟现在的工具发达,你可以查找--替换.不过程序是需要测试的,你替换一个地方,就需要多测试一个地方,成本高.对于C 多加一个实现接口的"小灵通" 类, 然后修改"手机工厂"的"获取接受者(st***号码) ". 一共2处,测试也只要再测试这个新类还有一个方法.C 方法面向对象的优势在这个时候体现出来了.有人这个时候出来抗议了,如果程序写的多了,经验丰富了,有人会看出我上面那些假设的漏洞,就是B 并不是最好的结构化方法, 因为其实有更好的用一个函数来实现判断类型那样就跟 C 一样,只要改很少的地方了.没错, 那样C和B又公平平等了,C还是没什么优势. 请注意2点第一: "面向对象" 不是指面向对象的编程语法, 而是一种思想. 那样写其实 B 已经拿到了一点面向对象的思想了只是封装在非面向对象的语法中. 第二不面向对象的确可以写出低耦合的,高效的,可维护的,很牛逼的程序. 但是那是需要很高造诣的人来做的事. 因为没有类的封装性,名字空间的隔绝还有全局性的变量在程序里走, 要靠程序员自己去避免这些"可以做,可以方便地做"却"会对未来维护带来灾难"的操作, 对程序员要求很高,你要自觉不用全局变量,就像以前自觉不用goto语句....还要自觉把功能分好摆好, 需要的分析设计技术是很高的. 而写出同样质量的面向对象程序,只要略知道设计模式的人就都可以了. 这就是面向对象大行的原因之一.有人说,面向对象就真的封装了?可重用了? 可是我看见很多C#和java程序错乱复杂, 根本拿不出一个"块" 出来用,你拿了"块A " 就调用到"块B ", 非要把"块B "也拿来..然后又要用到无关的C,D,E,F.....最后出来一大落,而且99.9999%是我不需要的,我就只需要那0.00001%而已....这是现实,的确,至少我看见的代码里垃圾代码占多数(这里是指可以实现功能却很"有臭味"的代码), 这主要有一个很大的原因是写代码的人没有面向对象的思想,有的只是面向对象工具包装的面向过程思想,而且连结构化都说不上. 不是面向对象的错.差不多,有些人现在认同面向对象了,也知道这不是书上随便说的那些苦涩的概念了,不过还是不明白怎么个面向对象法. 我再换个话题说说,不说手机吧,说衣服,服装厂生产衣服. 衣服有颜色,有大小,有款式.... 看看一个设计,在不同的人手里是什么不同的方法.现在服装厂要生产一批蓝色的, 小号的, 女款的...的衣服...A :衣服衣服1 = new 衣服();衣服1.颜色= 兰;衣服1.号码= 小;衣服1.款式= 女式;.....然后new 出好多件来.赋值好多下....现在问题是突然说不要兰的了要红的, 哎哟....改啊改.... 当然你可以在循环里做这个,但是如果每件衣服除了颜色和款式一样, 大小是不同的又如何?有个B想到了一个好的设计了.定义一个衣服类, 然后把大衣服作为一个子类,小衣服是另外一个子类. 那么方便了一些. 不过又有问题,如果再改需求.....要求大小跟男女固定的,颜色可以变,难道又再定义出兰衣服类和红衣服类.....那还有完没完啊........依然不是好设计.C面向对象有一个利器叫"设计模式", 学面向对象基本上这个是必修, 我们用用设计模式中的原型模式,构造出一个原型假设是一件大的男装, 然后通过Copy这个原型就可以得到一批大的男装,然后给各种颜色就行. 如果是再变化,那么我们不需要什么变,只要再构造另外一个原型,然后用代码Copy这个原型,又可以试用新的变化了....(今天的内容基本是面向新手级程序员和学校里的高手学生的,未完待续....接下来将会是一个完整的面向对象设计分析例子,真正体会面向对象的优势和如何面向对象分析设计)。
