.net(C#)开发小技巧漫谈之二_[Asp.Net教程]

五，关于面向对象在项目开发中的运用

面向对象时下很火，是地球人都知道了。做为一名程序员似乎不会面向对象就显得很土。关于面向对象，如果目前还不懂，请不要在项目开发中自主运用。如果需求把握不好，颗粒度划分不好，反而得不偿失。一个优秀项目的架构绝非易事，在目前的中国做公司项目开发，没有人给你那么多的时间容你去细细思考。这时候用通用的模式开发，采用现成的类库、组件，一失为明智之举。如果开发自己的项目，倒是可以慢条斯理，以下是我的看法。仅是个人之见，仅供参考。

在.net(C#)开发小技巧漫谈之一中，第一个小技巧提倡使用getter与setter属性存取器，代替对变量直接读取。这个原则实际是[开放封闭原则]在变量这个层次上的运用。开放封闭原则的核心意思是，对可变可见的元素仅向客户代码提供唯一的操作通道。
第四个小技巧提倡用接口代替类用于类间传递，实际上是[依赖倒置原则]针对接口的应用。依赖倒置原则的核心意思是，细节之间不应该相应依赖，他们彼此都应当依赖于抽象。
为了进一步阐述的需要，现列举列位已经司空见惯的耳熟能详的赫赫有名的五大面向对象设计原则：

1. 单一职责原则
2. 开放封闭原则
3. 里氏替换原则
定义：如果对于类型S的每一个对象o1，都有一个类型T的对象o2，使对于任意用类型T定义的程序P，
　 将o2替换为o1，P的行为保持不变，则称S为T的一个子类型。
4. 依赖倒置原则
5. 接口隔离原则

这五个原则每一个都还有一个三个字母的缩写，不再列出。对于这六个原则，一直都在思考，但一直都未能理解。
单一职责讲的分摊责任，责任到个体，一个对象只负责一件事情。而接口隔离原则，讲的是一个接口只担任一个角色，我不明白两个原则有什么区别，讲的不是意思吗，干吗还要分成两个原则分别定义，并且还加个英文缩写，冠冕堂皇的像高等数学公式，特别是里氏替换原则的定义。
一个对象如果其内部对其它所有对象都是不可见的，那么这个类便毫无用途；相反，如果全部可见，则可能是最糟糕的设计。封装是促使类产生的直接原始原因，也是面对对象的第一原则。因为封装，我们要用setter与getter把变量封装起来；因为封装，我们要用方法把类封装起来。而客户代码对对象的读取、操作必须按照我们预定义的通道。这也是[开放封闭原则]表达的思想。人有五官，眼睛是看的唯一通道，而耳朵是听的唯一通道，人不能用脚听、用屁眼看，大自然创造人也应用了封装的思想。
对于两个方法，如果传进去的参数相同，返回的结果也相同，那么这两个方法还不可以认为是相同的吗？至于两个方法的内部各是怎么实现我们大可不必关心。根据这个朴素的原理，接口产生了。面向接口编程也顺理成章成为了面向对象编程的第二个原则。[接口隔离原则]是对面向接口编程的一条修饰。[依赖倒置原则]实质也是面向接口编程。
关于面向对象，纵向来说有继承、多态，横向来说是组合编程。很多高手推荐组合编程，因为组合编程可以改变对象本身。对象本身都可以改变了，还有什么不可以改变的。组合编程是在面向对象设计中常用的伎俩，可以作为第三个原则。如果需求有变，运用组合编程的设计的改动将可能是最小的。
对于一个对象，它有哪些因素？原始材料（参数，内部变量、对象）、加工策略、返回格式。所谓的设计模式是对这三者（要么是接口编程，要么是组合编程）在不同层次以不同方式的改变。如果这三者都可以改变，那么这个对象是最灵活的了，但恐怕也没有什么作用了。如果什么都不能改变，那么当需求变化时，灾难便来临了。
我们说，一个类只负责一件事情，那么这一件事情的单位是如何划分的，究竟多大也才是“一件”。对于腿负责走路这件事情，它是由大腿小腿以及膝关节协调完成的，看见了吧，这“一件”事情又分为了许多个“一件”。于是系统架构产生了颗粒度的概念，产生了微架构的思想。
系统设计的颗粒大小是与需求的颗粒大小是对应的。细到哪个层次，还必须由需求来定。具体问题具体分析，在编程领域也两样适用。这项功夫需要在项目开发中磨炼。

在系统架构中，我个人觉得应该：
其一，不应该受到细节的干扰。写到这里，我想起了那个家喻户哓的赵本山与宋丹丹表演的小品：

请问把大象装进冰箱里分为几步？

第一步把冰箱门打开，第二步把大象装进去，第三步把冰箱门关上。

其二，要考虑具体语言的特性。譬如，AS3不支持私有的构造器，运用Singleton模式就受到影响。AS3中有事件广播机制，可以利用它使用Command模式。
既要忘记细节实现，又要记住其语言特征，这似乎是矛盾的。是矛盾的就对了，这世间的东西没有一件不是矛盾的。

来源:sban's .net blog(cnblogs)