C#使用面向对象原因介绍
2010-04-14 21:41 宝宝合凤凰 阅读(432) 评论(0) 收藏 举报摘要：面向对象是什么？为什么要面向对象编程？本文介绍什么事面向对象和C#使用面向对象原因。
面向对象（OOP）的四大特征：
抽象：我的工程应该有哪些类--我们通过观察数据库设计，可以帮助我们找到类
封装：自己的事情自己做，不要过多的暴露自己内部的事情
继承：类与类之间的兼容关系，事物之间的关系不只是平级关系，还有抽象与具体的关系（笼统和清晰的关系),他们之间是兼容的
多态: 一个方法，对应多种实现方式（多种形态），调用一个方法时，应能智能准确的调用
为什么要使用类：因为把有规律的东西压成模板，能简化开发，是一种技巧，能按人的逻辑进行组织代码
为什么使用static：因为在一种事物中（一个类)，有些是公共的特征（例如人类的总数)，有些特征是因人而异的(某人的身高),我们把公共的特征和行为标记为static，它不需要new（不需要依赖于new出一个 个体)就能使用
为什么要使用构造函数：为了避免必要的原材料缺失
为什么要使用函数重载：把方便留给客户，多种类似的业务，不要提供太多的服务窗口
为什么使用属性(get set):是变形的方法：用起来像字段，实际上是方法 ，这种方法的功能主要提供内部数据的过滤（像数据库的check约束一样）
为什么使用索引器：也是变形的方法，有机会给大家使用[]的语法
为什么使用常量（const) 因为工程中统一管理固定的约定值，会有条理
为什么使用枚举（enum) 因为表达几个状态，用可选项的方式更好，必须在其中选其一
为什么要使用结构(struct) 因为学习了堆栈图后，知道struct不需要按线索行事，体积小时效率高，但要谨慎用它，因为容易有装拆箱的问题，内嵌类时还会混乱，体积大时没有效率
为什么要了解装拆箱：因为装箱是自动的，希望大家尽量避免装拆箱，而不是让大家学习如何装拆箱
为什么集合（List，ArrayList):因为数组长度不好管理，我们需要动态增长的数组
为什么首选泛型集合（List<>):因为ArrayList是垃圾筒，而且对值类型提供的服务不到位(需要装拆箱)
为什么选择字典：因为List集合查找速度慢，有频繁查找的情况要考虑字典集合，但注意其中分keys 和Values集合，要绑定还要转换一下
为什么要用XML传输数据：因为xml格式可以把文本文件表达清楚层次感，要在经过公网获取数据，直连数据库来获取数据是很危险，由服务端把数据搜出来，通过清晰的xml表达方式再把文件传给对方解析
为什么要用Xml配置数据：因为用文本文件，表达太简陋，一旦许多东西要配置，就混乱，所以利用xml能清晰的表达的能力
为什么使用IO流来存取数据：因为不是什么都要动用数据库的，例如简单的信息保存
为什么要用序列化：就像重装电脑，使用ghost这种连皮带壳的方式比，普通的一个一个软件装的方式要好，别忘了普通的方式是先拆后装工作量很大
为什么要用序列化传输数据：简单，高效，整体保存，整体还原
为社么有的时候要用XML而不用序列化的方式传输数据：因为序列化技术中，传输双方都要约定使用共同的类来保存和还原数据，导致了部署上的特殊要求，以及只能用于同一平台，xml虽然低效，但没有这些缺点
为什么要使用反射：反射是透视机，不仅能够看到程序集及类内部的结构，而且能够通过基因type来克隆出对象，令我们可以凭空的使用一个程序集和类（通过路径字符串和类名字符串即可），而无需在工程中事先导入，在不方便导入的情况下，发挥着不可替代的作用
为什么要使用继承：继承描述的是类与类之间的兼容关系，使用继承能帮助我们分解复杂的问题:我们的问题一旦复杂，我们解决的方式是分类处理，逐项攻破，继承就是个笼统的问题，分门别类成具体的问题（子类),还复杂就继续细化，这种分解就是继承的使用
为什么需要多态：我们发现继承仅仅是解决了兼容关系，兼容导致多个类可以混在同一个集合中，但是当你发号施令时，不代表每个类对象都知道要调用自己的方法。（如果不能准确调用各自因人而异的方法，那么兼容就毫无意义），所以我们使用多态的语法来解决自动调用的问题。
====================
是什么限制了我们面向对象（的开发）
今天看到CSDN中的两个讨论贴，一个帖子在说技术经理不允许团队成员使用面向对象的方式开发程序，另外一个帖子（找不到地址了）说某个团队成员在尝试使用面向对象的方式设计和写程序，但是遭到了其它程序员的鄙视。
或许你也在郁闷，为什么跳槽了这么多公司，想学一些面向对象的开发方式，怎么弄来弄去都还是基于对象（基于面向对象框架的开发）的开发呢？我想，其中的原因可以从几个方面来说：
公司
1. 公司性质
如果公司本身就是一个面向小客户（比如制作小网站）、面向外包的小公司，或者公司并不小，但是公司的开发团队仅仅属于公司的后勤部门，开发的产品并不能给公司带来利润等等原因都可能使得开发向简单化、过程化发展。
2. 管理团队
就像前面那个网友说的，技术经理不允许面向对象开发。可能技术经理看的是项目的维护性、看的是项目的进度，而没有看到项目远期的维护性和扩展性。也可能技术经理并不反对，而他的上司是非常看重眼前利益的，技术经理也无能为力。管理团队的任何一个层次都可能会对开发模式产生影响。
项目
正因为有前面说的那些公司，导致项目往往有以下的特点：
1. 项目进度非常赶并且一个接一个。我们除了能运用成熟的开发流程、框架之外哪里还要时间思考过多的问题呢？
2. 项目的可维护性和可扩展性不重要，甚至有的项目要求就是可维护性差、可扩展性差（公司希望项目卖出去之后从客户那里获取更高的维护费用）。
3. 项目非常小，而且偏向于网站。由于网站以数据为中心、业务逻辑较少并且注重性能的特殊性，要在这样的项目中推行面向对象的开发确实是实际效果比较差的。
团队
由于公司的性质或项目的性质就导致了产生了这样的一些团队：
1. 开发人员水平参差不齐。这里的水平包括基础、经验以及学习能力。由于面向对象需要开发人员有一定时间的OO思想的积累，对于这样一个团队，即使推行了OO，不知他们之间的协作会有什么问题呢？
2. 开发人员没有良好的OO背景。有些人以前是做ASP的，有些人以前是做VB的，可能对于做ASP.NET的开发人员来说有ASP和VB背景的人比较多。这样的话就会导致难以整体转化开发思想，即使转换了，代价也比较大。
3. 团队中没有对OO经验丰富的人，或者从组织结构上说，团队中并没有设计师的角色，项目经理手下都是普通“老百姓”。
4. 团队的学习气氛不好。很多团队死气沉沉，上班-下班，团队中也有很多年龄较大的程序员，要在这样的团队中推行新的开发思想确实很难。
5. 团队过于庞大。
6. 更极端的情况是，团队中所有人都是只会增删改的初级程序员，而项目经理完全不懂技术（招聘的时候只求工资低，面试只看是不是会使用控件进行增删改）。
技术
如果团队已经习惯了基于过程化的开发，那么要向面向对象开发进行转换还需要解决非常多的关键问题：
1. 持久化
关系型数据库和领域（业务对象）模型之间有比较大的差异，我们不得不依靠一些ORM框架来实现业务对象的持久化，ORM框架的性能、ORM框架的学习难度、ORM框架的可靠性都是在把框架应用到项目中需要考虑的问题。
2. 对象呈现
业务对象往往是相互关联的复杂结构，而UI往往是平面化（一维或二维）的趋向于关系型数据库一种表现方式，这个转换过程可能会很复杂，所谓的面向对象是不是没事找事把关系型数据转化为业务对象，再把业务对象格式化成UI喜欢的数据源（比如DataTable）呢？
3. 性能
前面说的2点都可能会产生性能问题。首先，表现层是否需要完整的业务对象，其次，是否需要从数据库中获取完整的业务对象。如果界面上只希望显示10K数据，而ORM框架却从数据库中获取了100K数据并且把它们都传给了表现层，是不是不太合理？如果说还引入了分布式的话，那么网络上传输的代价就会更大。从小的层次来说，面向对象本身就或多或少降低了性能。
主观原因
如果上述这些客观原因都不存在的话推行面向对象开发还有难度，那么可能还有一些主观原因存在：
1. 给自己很多不使用OO的理由。拿到项目了，总是想项目太小、进度太紧，算了这次不尝试OO了，以后遇到其它项目再来尝试吧。没有小项目的思考，怎么能遇到大项目而不慌乱呢？
2. 没有责任心。希望尽快结束项目，在项目可维护性变得很差连自己都不想维护的时候往往也是我们引咎辞职的时候。
3. 没有转换的动力。大家沉浸在一个不错的过程化开发过程中，宁可愿意把维护的工作留给新来的同事也不愿意去尝试新的开发过程。
理想的环境
你或许一直在寻觅这样一个环境：
1. 不错的公司，从事大型企业级软件的开发，有着经验丰富并且开明的项目经理。
2. 项目周期长、项目大且复杂，客户对项目的维护性和扩展性要求比较高。
3. 团队中不乏经验丰富的构架师和OO达人，团队讨论气氛良好。
4. 有完整的基于面向对象的解决方案，开发流程非常正规。
说实话在国内确实很少。很多时候，我们能看到的也仅仅是在表面上非常好，而在真正的开发过程中发生扭曲的环境。
说说我们的情况
1. 项目是为公司的产品服务的，团队的产出不会给公司带来直接利润，也不是公司的技术核心。
2. 团队不大，团队成员水平相差较大，以我为90分的话，那么团队中有20分的，也有80分的。几乎所有人都有非OO语言的背景，也可以说是由于ASP.NET而接触C#的，而不是由于C#而基础ASP.NET的，导致基本没有任何OO概念。
3. 项目都是不超过2个月的超小项目，甚至会有很多2天的“项目”（其实就是做一个页面）。项目基本都是以数据为中心的网站，而且对性能要求非常高。项目对时间要求非常苛刻，说好这个时间点连一天都不能晚。
基于这些情况，我思考了很久还是决定以一套学习曲线低的构架、流程来开发这些项目。不过，这并不是说我们永远就是过程化开发了，我会在时机成熟的时候把一套合适的面向对象开发流程推给团队（请注意这里的“时机成熟”以及“合适的”两个词）。个人认为，只要有明确的开发方式、相对成熟的开发框架，上面的3点并不能挡住我们OO的脚步（“我们”仅指我们团队），只不过，我还在寻找一个合适的切入点。
讨论
基于这些客观或主观原因（其实，往往这些原因是交错的，因为这个也就产生了那个），真正面向对象的开发（包括完善的开发流程）在国内大多数公司（包括我们公司）中难以推行，（由于快下班了，我并没有过多去思考改善的方法）请大家讨论…………（本文只是总结一下现况，并不表达过程化开发和面向对象开发的优劣）
=====================================
31. 案例分析：面向对象得失论
缘起最近一段时间，在博客园关于面向对象的讨论比较热烈，你来我往的，好不热闹。不完全归纳一下，大约有以下几种意见比较受欢迎：A. 面向对象需要组织、团队支持，需要一种环境；B. 面向对象比面向过程编程要...
30. 为什么无法面向对象
条条道路通罗马，能解决问题的都是好办法。1. 产品需要满足用户需求。每天都在用windows、ie、word、firefox等，都很好用，但对用户来讲谁关心后面的代码、架构是什么样子。生产线上的人每天...
29. 外国人眼中的面向对象
先撤点别的：）一直觉得博客园的氛围很好，有什么事大家可以一起讨论。看到博客园里讨论面向对象，感到非常欣慰，因为我也喜欢面向对象。对于非数据库相关项目来说，可以直接套用面向对象的理论，对我们来说没有什么...
作者：Nathan2008 有2625人浏览 评论(14) 发布于2007-11-03 20:28
28. 原来，面向对象和数据库是“冤家”
原来，面向对象和数据库是“冤家”没经证实的传说话说当年面向对象和数据库刚出道的时候，曾经引发过惊天动地的大讨论(当然，这里说的是关系型数据库,以下简称数据库)。两个阵营的人都试...
作者：Nathan2008 有2663人浏览 评论(19) 发布于2007-11-03 13:11
27. 是什么限制了我们面向对象（的开发）
是什么限制了我们面向对象（的开发）今天看到CSDN中的两个讨论贴，一个帖子在说技术经理不允许团队成员使用面向对象的方式开发程序，另外一个帖子（找不到地址了）说某个团队成员在尝试使用面向对象的方式设计和...
作者：lovecherry 有5793人浏览 评论(65) 发布于2007-11-02 18:19
26. 分层模式下的Lazy Load ——探索Domain Model系列（下）
你知道的，我儿啊，为父只有一句话要对你说，那是为父这一生来奉行的格言： “勿以恶小而不为，勿以善小而为之。” 切记切记啊！ ——Icecream 风聆 《魔王爸爸的16封信》 ...
25. MapperRegistry 是工厂方法的变形？ ——探索Domain Model系列（上）
“请问我从这儿出发应该走哪条路呢？” “这多半看你要去哪儿。”猫说。 “我不太介意去哪儿——”爱丽斯答道。 “那你走...
24. 随笔：杂念纷呈
虽然没有任何证据明确指出“一切皆对象的”概念，但如果采用了面向对象思想来分析并模拟一个系统的行为时，就最起码必须要遵守“尽量把一切转化为对象”的原则。即...
23. 别在领域模型迷失了自己
本不想对这个图书馆再掀话题﹐看了亚同志的重构图书馆惊魂夜﹐觉得还是有必要完整地解释一下图书馆与领域模型﹐毕竟这个问题由我而起﹐善终一下吧。首先把图书馆系统的背景说明一下吧﹕公司每个成员通过局域网登录图...
22. 重构图书馆惊魂夜（理解模型，关注设计）
前一篇Post因为绘图的关系导致理解上有所误区，所以重构一下，重新更新了图形，让我们重新来审视一下这个被多次讨论的设计。 首先是图书馆的用例： 其实用例的情况大家都很清楚了，简而概之就是用户在图书馆的...
21. 对最近讨论的看法
最近的讨论比较激烈，我看来其实主要思想偏向有两种，一种是学院式的研究探讨，另一种声音是希望讨论能更偏重于如何进行实际运用。我的观点是支持后面一种。例如book.Save()到底是否面向对象，用法是否优...
20. 没有银弹，但可以"扯蛋"
最近园子里的book.save()计论已让我看的有些厌恶了。同时也希望大家不要再在这个问题上火上浇油了。有关这个问题在别的技术社区早就有过讨论(不要吃人啃过的馍)，最后又怎么样呢？ 还是希望大家务实点...
19. 图书馆惊魂记之一（一个简单的领域模型的建立过程）
在大学里的某一天，一个漆黑的夜晚，我来到了一个学校里阴森的图书馆，虽然说不喜欢，但是为了考试不要零蛋，所以拼死也要温书了。来到图书馆的柜台前，遇到了图书管理员。然后我跟管理员说：“我来借书...
18. 领域模型﹐打开OO的另一扇窗
园子里这么多讨论OO的﹐我也来凑一下热闹吧。面向对象开发一个最重要的思想就是对真实世界进行模拟。然而﹐在大量的使用面向对象语言开发的系统中﹐您却很难看到这种模拟﹐而依然是些以数据库为中心的增删改查动作...
17. 为什么把持久化放到Domain Object是不OO的.
争论会一直在人群中存在,它消失就代表人类文明也灭亡了... 很久以前,在园子曾经出现过关于ORM的争论.而就是在那段时期,我对OO及ORM的概念在硝烟弥漫的文字里逐步建立起来.最近对于是不是该把持久化...
作者：Klesh Wong 有1737人浏览 评论(53) 发布于2007-09-24 17:07
16. 贫血或职责的讨论
先来点题外话，亚历山大兄弟最近的几篇文章不错，不用太在意细节，揪住细节使劲儿打的家伙很无聊的...至少我从你的文章里也重新学习了不少东西，不是客气话；我这人基础功很不牢靠的。现在直奔主题吧，咱们也来选...
15. 怪怪设计论闲谈篇：职责与解耦的矛盾
正式讨论之前，先看看这两个问题：当我们的对象所涉及的操作不断增加时，我们是否应该：Book.Save，Book.Serialize，Book.Method1，Book.Method2这样一直增加下去？...
14. 关于OO的后现代争论几时休
最近园子首页被（o）（o）充斥，本来讨论技术时间极好的事情， 只是作为一个后学者来说 俺要说说自己的看法。各位前辈高人纷繁抛出自己的心得的时候，也顺带着反驳了他人的观点，有时候是bs了一下别人的观点。...
13. 开一个讨论，说说我封装的看法【初学者谨慎观看，未成年人请在家长监督下观看：）】
上一篇Post效果不是很好，既然大家喜欢讨论，我就还是用讨论的形式来进行。这次还是接着上一次的话题，封装，可能是因为没有表述清楚，所以导致了很多Tx有所疑问，所以这里更加详细的阐述我对于封装的看法。=...
12. 噢,这就是封装啊?!
其实本人完全不太明白什么是OO,而且现实中做的东西也不是很OO.刚才拜读完亚历山大同志《又见手把手系列-面向对象扫盲-通俗的OO第一弹-【封装】》 深感茅塞顿开,终于大约地知道一点点啥是OO,亚历山大...
作者：Klesh Wong 有2321人浏览 评论(46) 发布于2007-09-22 10:12
11. 又见手把手系列-面向对象扫盲-通俗的OO第一弹-【封装】
最近针对OO有了太多的讨论，太多的误会，太多的不理解。让我来一次性解决什么是对象，为什么要面向对象的问题吧，这是第一篇。所谓面向对象的编程、设计、思想。我们用大白话来说。面向对象就是用 某物（对象），...
10. 煽风点火:也论Bjarne Stroustrup的"基于对象"的含义, 同时B4一下大师
这篇文章在我看过原文之后, 确认是一种误解, 当个消遣看的话, 里面还有点东西, 不过价值不大, 切不可当真! 理解本文的关键是, 确认其中"编译时刻确定"所包含的内容:本文中"编译时刻确定", 包括...
9. 也乱弹Book.Save而引OO对话
这几天博客园热闹的几乎是OO讨论.我在这里不会详细解说何为OO.因为我对OO的概念也是一层薄纸，只要随便一捅就很容易穿的……而我写此随笔主要是我刚看了亚历山大同志的“...
8. 我对oo的看法（对最近关于oo的认识）
看过该文大家的回复，感觉这里的讨论的气氛不错，彼此宽容，相互探讨才可以有进步。发表一下自己的看法：1、oo必然有其价值：要理解这个价值我个人认为（请各位tx指正），要从oo的来源理解。一、oo从何而来...
7. 其实添加数据也可以这样简单——表单的第三步抽象（针对UI及后置代码）
终于赶出来了，现写了一遍代码。感谢大家的支持，感谢大家提出自己的看法。衷心的感谢，真的。应该是先写第二步的，但是想一想还是先写第三步吧。一般大项目里面都会有很多的基础信息的表，比如学历、职称等等，最近...
6. 软件设计基本原则
1,没有银弹.2,客户需求是一切设计的根本.3,使用你的程序的人就是你的客户.别拿同事不当客户,也别拿自己不当客户.4,判断设计优劣的唯一标准是客户用起来爽不爽.5,抽象得好与不好全看你的需求会怎么变...
5. 谈谈book.Save()到底OO还是不够OO
在之前争论贫血还是充血的时候，有Tx提出这样一个观点book.Save()用起来很怪，有人认为这样子的用法不够OO，因为保存书不是书所具有的行为，而是书籍管理员：BookManager来发出比较合理。...
4. 一个必须使用面向对象才能写出来的超简单的程序。为亚历山大助威
招砖头了，有错就改标题应该是：一个很能体现面向对象思想特色的超简单的程序。为亚历山大助威看了亚历山大同志写的捅破窗户纸一文还是有所感觉的不过亚历山大同志明显学究气氛浓重不好意思在这里表露真实身份了。本...
3. 捅破窗户纸：如何从过程到对象—For金色的海洋以及所有为面向对象而困惑的Tx
本来不想写这篇很挨打的Post，不过在最近几天的最热的几篇Post里面看到无数的Tx为了面向对象的争论，感触颇多，遂作此篇。鄙视OO的也进来鄙视我吧。望OO达人多多指正。前头有一篇关于对象持久化的。不...
2. 其实添加数据也可以这样简单——表单的第一步抽象（针对数据访问层）《怪怪设计论: 抽象无处不在 》有感
更正：不好意思，昨天晚上思路有点混乱。有几个前提忘记说明了，现在补充一下。1、缩小范围。按照由简到难的思路，这里先讨论最简单的添加数据的情况。就是单表的添加和修改；这里讨论的是webform的情况。2...
1. 怪怪设计论: 抽象无处不在
现代的软件科学中, 很多内容和概念, 实际上是从数学/语言学等相当古老的领域里借来的, 为什么呢? 因为软件科学中的很多方面, 与其它学科中所碰到的问题并无不同. 一套数学理论，某个数学公式，无论从哪...
浙公网安备 33010602011771号