《OO设计原则总结》一文中我提出了一个问题:如何更好的使用这些原则?怎样在实践中遵守这些原则,使用三种视角思考问题就是答案之一;
本文内容包括:
1.为什么我们过早的纠缠于细节?问题的本质是什么?
2.救命稻草--Martin Fowler的三层视角理论
3.三层视角--回头再说OO设计原则
为什么我们过早的纠缠于细节?问题的本质是什么?
做设计时过早的关注细节几乎是多数程序员的泥沼,也是我自己的顽疾。就像我刚开始工作不久要做一个自动更新的系统,设计会议上开发组老大定了使用FTP协议完成,你知道我脑袋里面想的是什么?--“Indy组件好像不支持中文”…...
过早的关注细节,大体上可能有两种原因:1.经验丰富,举一反三,纲举目张,各种技术玄妙如数家珍 2.没有什么经验,只知道点技术细节,难以跳出思维桎梏;我知道我是后者,以前是现在也是。
人是有惰性的,人们习惯性的做自己熟练精通的事情。所以做设计的时候,当对大框架缺少把握能力的时候,潜意识里我更愿意去思考那些细节。这是在偷懒,所有的技术细节、问题都是没有疑问的(我们不是做科研),或者是有疑问你可以很容易获得解答无论是开发文档还是在社区。细节的解决方案总是显而易见,但并非肯定是最好的入手点。
有时候我真的要做设计了,我想要避免陷入“细节泥沼”可是我还是无意中把细节扯进来,这是为什么?剖析自己,我知道这是因为我的思考是平铺的,是没有层次的,所有的问题搅在一起,做设计的时候难免拖泥带水,泥沙俱下。
思考没有层次这就是问题本质所在,我要做好设计,而思维方式上的缺陷成为我的命门所在,我该怎么办?说实话我一直在走弯路,而且不知道现在的这条路是否对头。
“善良的人在追求的中纵然迷茫,却终将意识到有一条正途.”-----《浮士德》
救命稻草--Martin Fowler的三层视角理论
Martin Fowler在他的著作 《UML Distilled》中提到了三层视角(perspective):概念视角,规约视角,实现视角。
使用三种视角看软件开发,我们可以得到这样的描述:
概念视角:呈现所研究领域中的各种概念,得出概念模型的时候应该尽量少德或者不考虑它的实现,这个视角要回答的问题是:软件要负责什么?是策略性的结论
规约视角:我们现在考虑的是软件,但是我们关注的是软件的接口而不是实现。规约视角要回答的问题是:怎么使用软件?这个层次关注的是软件各部分的交流。
实现:这时我们考虑的是代码本身但是许多方面我们使用规约视角可能会更好,软件在规约层交流在实现层执行。
视角帮助我们将问题划分层次,隔离
从上面的描述我们很明显得看到“软件开发”所设计牵扯的问题已经被划分到三个不同的层次,在每一个层次我们都要有特定的思考成果。在高层没有思考成熟的时候我们不往下一个层次进行,按照这样一个原则,细节被隔离在思维的围墙之外。
下面一个问题就是,在设计中过程,三种视角对问题进行层次划分能起到什么作用?
三层视角--回头再说OO设计原则
概念视角我们得到了领域的各种概念,对象要负责什么?这是一个高层策略,它通常是高度抽象的,是一个策略性的结论,关键一点:它是稳定的。只要概念不变请求者就和细节的变化隔离开了;细节问题的处理应该尽可能的往后推迟。关注对象要做什么,而不是怎么做,将这些细节实现隐藏起来帮助我们免于过早的介入细节。关注对象要做什么,就是在定义对象的责任,理解对象的最佳方式就是把它看作有责任的东西。
规约视角,对象是一组可以被其它对象或对象自己调用的方法(也就是行为,怎么使用软件?);对象是有责任的我只需要关注对象的公共接口-这是我要求对象完成某些工作的交流渠道。只要对象的接口告诉我们它可以完成某项职责,不关注对象是怎样运行的。关注动机而非实现,是基本的OO设计原则,将实现隐藏在接口之后实际上是将对象的实现与它们的对象解耦了。
实现视角,对象是代码和数据,以及它们之间的计算交互(软件怎么履行自己的责任?);走到这里我们才开始讨论实现细节。
总结一下,从Martin Fowler的三个视角来看对象:
在概念层次上,对象是一组责任
规约层次上,对象是一组可以被其他对象或者对象自己调用的方法
在实现层次上对象是代码和数据,以及它们的计算交互
到这里我们需要对OO基本原则做一个再思考了:
从概念层到规约层我们的思考成果都是抽象的,他们是一个个抽象的概念,是一个个的行为;我们在概念层是对象的责任清晰化,在规约层我们看拥有不同责任的对象之间是怎样协作的。协作方式就是一种对象与对象之间的契约。对象的责任怎么划分?对象应该对自己负责,对象的责任应该尽量单一,这就是SRP原则。规约层我们定义的是对象间的交互契约,也就是接口,关注接口而非实现,我们做到了。
概念层是最稳定的,规约层次之,实现是最不稳定的。所以高层模块不应该依赖低层模块,两者都应该依赖于抽象。细节应该依赖于抽象,这就是DIP原则。这个原则隐含的意思是:对象之间只在概念层次存在耦合,在实现层次不能耦合!
我们定义的所有交互都是使用基类,那如果实现的时候某一个子类不能完全代替基类呢?那是不是所有的交互契约都出现问题了?一个从基类派生的子类应该支持基类的所有行为,子类必能替换基类,这就是LSP原则。
可以看出对象的责任和交互被尽早的定义出来,这个过程中我们没有考虑具体对象在什么时期创建,映射到我们的设计过程中,创建型设计模式的应用往往是在设计的后期。
结论:
《OO设计原则总结》一文中我提出了一个问题:如何更好的使用这些原则?怎样在实践中遵守这些原则,使用三种视角思考问题就是答案之一;
做设计时,注意力首先要放在高层关系上;
在面对对象设计开发过程中以概念 规约 实现三个视角类思考问题能提高我们的设计能力,避免过早陷入细节泥沼。
附: Martin Fowler著作 《UML Distilled》提到三种视角(perspective)的段落:
Following the lead of Steve Cook and John Daniels (1994), I say that there are three perspectives you can use in drawing class diagrams- or indeed any model, but this breakdown is most noticeable in connection with class diagrams.
-
Conceptual.
If you take the conceptual perspective, you draw a diagram that represents the concepts in the domain under study. These concepts will naturally relate to the classes that implement them, but there is often no direct mapping. Indeed, a conceptual model should be drawn with little or no regard for the software that might implement it, so it can be considered language-independent. (Cook and Daniels call this the essential perspective.)
-
Specification.
Now we are looking at software, but we are looking at the interfaces of the software, not the implementation. Object-oriented development puts a great emphasis on the difference between interface and implementation, but this is often overlooked in practice because the notion of class in an OO language combines both interface and implementation. This is a shame, because the key to effective OO programming is to program to a class's interface rather than to its implementation. There is a good discussion of this in the first chapter of Gamma, Helm, Johnson, and Vlissides (1995). You often hear the word "type" used to talk about an interface of a class; a type can have many classes that implement it, and a class can implement many types.
-
Implementation.
In this view, we really do have classes and we are laying the implementation bare. This is probably the perspective used most often, but in many ways the specification perspective is often a better one to take.
Understanding perspective is crucial to both drawing and reading class diagrams. Unfortunately, the lines between the perspectives are not sharp, and most modelers do not take care to get their perspective sorted out when they are drawing. Although I've found that this often does not matter too much between the conceptual perspective and the specification perspective, it is very important to separate the specification perspective and the implementation perspective.
As I talk about class diagrams further, I will stress how each element of the technique depends heavily on the perspective.
Perspective is not part of the formal UML, but I have found it extremely valuable when modeling and when reviewing models. The UML can be used with all three perspectives. By tagging classes with a stereotype (see page 79), you can provide an indication of the perspective. You mark classes with <<implementation class>> to show the implementation perspective, and with <<type>> for the specification and conceptual perspectives.
《UML Distilled Second Edition A Brief Guide to the Standard Object Modeling Language》
Martin Fowler Kendall Scott
Publisher: Addison Wesley
Second Edition August 18, 1999
ISBN: 0-201-65783-X, 224 pages
原文:http://www.cnblogs.com/me-sa/archive/2008/04/15/ooview.html
分享到:
相关推荐
### OO设计原则 -- OO设计的 DIP依赖倒置原则 #### 概述 在软件工程领域,特别是面向对象设计中,依赖倒置原则(Dependency Inversion Principle, DIP)是六大设计原则之一,由著名软件架构师Robert C. Martin提出...
### OO设计原则——里氏替换原则详解 #### 一、引言 面向对象设计原则(Object-Oriented Design Principles)是一套指导软件开发者如何更好地设计类、接口等面向对象元素的原则集合,旨在提高代码的可复用性、可...
### OO设计原则总结 #### 什么是设计原则? 设计原则是一系列指导软件开发的基本准则,遵循这些原则可以帮助开发者构建出更加灵活、易于维护和扩展的软件系统。这些原则旨在解决常见的软件设计问题,如耦合度高、...
第一册:《Head First Java》是本完整的面向对象(object-oriented,OO)程序设计和Java的学习指导。 第二册:《HeadFirst设计模式》(中文版)共有14章,每章都介绍了几个设计模式,完整地涵盖了四人组版本全部23个设计...
JSOO是JavaScript中面向对象编程的一种设计模式,它模仿了传统面向对象语言如Java或C++的类和对象概念,使得JavaScript代码更加结构化和易于维护。在WebGIS项目中,JSOO常用于构建复杂的地理空间对象模型,如地图、...
标题和描述中提到的"2oo2安全计算机平台的动态周期设计方法及系统"是一种专为确保设备安全性和可靠运行而设计的技术方案。2oo2可能代表某种特定的规范或者标准,这在行业内通常用于指代系统的安全等级或可靠性要求。...
在“hit9-oo”项目中,主要包含的文件是“oo-master”。这个目录很可能包含了项目的主脚本文件、辅助工具和相关的文档。通常,这样的脚本会利用操作系统提供的环境变量、安装路径以及Go语言的版本管理工具(如gvm:...
### OO设计原则精要解析 #### 封装变化:Encapsulate what varies 在软件设计中,变化是不可避免的。封装变化原则强调将系统中易变的部分与不变的部分分离,通过封装变动点,使得系统其他部分不受其影响,从而保持...
在本文中,我们将详细探讨OOP设计中的五大原则:单一职责原则(Single Responsibility Principle,简称 SRP)、开放封闭原则(Open-Closed Principle,简称 OCP)、里氏替换原则(Liskov Substitution Principle,...
《OO设计五个原则》深入探讨了面向对象设计(Object-Oriented Design,简称OO设计)中的五大核心原则,这些原则是软件工程领域公认的基石,旨在提高软件系统的稳定性、可维护性和可扩展性。本文将详细解析这五大原则...
Java面向对象设计原则是软件开发中的基石,它们指导着我们编写出高质量、可维护和可扩展的代码。这些原则包括单一职责原则(SRP)、不要重复代码原则(DRY)、开闭原则(OCP)、里氏替换原则(LSP)、依赖倒置原则(DIP)以及...
### OO设计根本的指导原则 面向对象(Object-Oriented,简称OO)设计是软件工程领域内一种重要的设计理念,它通过模拟现实世界中的对象及其相互作用来构建软件系统。为了确保设计的质量,遵循一系列的设计原则至关...
数据集“包含高斯-埃尔米特正交规则,用于积分在区间(-oo,+oo)上,使用“物理学家”权重函数”是一个专门针对数值积分问题的资源。在这个压缩包中,主要包含的是“quadrature_rules_hermite_physicist”文件,它...
### 设计模式的六大原则 - **单一职责原则**(Single Responsibility Principle, SRP):一个类应该只负责一个功能领域的职责。 - **开闭原则**(Open-Closed Principle, OCP):软件实体应该对扩展开放,对修改关闭...
### 泛型编程与对象导向编程(GP/OO) 侯捷在雅虎所做的报告主要围绕泛型编程(GP)、对象导向编程(OO)以及C++展开。这表明报告内容将深入探讨这三种编程范式的结合运用,尤其是在C++这一具体语言中的应用。 ###...
Flask-restful-api:遵循OO原则,使用SQLAlchemy,jwt身份验证进行简单的API REST
ex2-fishee82oo-submit-history.zip
Ruby-Pundit是一个强大的授权库,它鼓励使用面向对象的设计原则和纯Ruby类来实现细粒度的权限控制。在Ruby开发中,特别是在构建复杂的Web应用程序时,身份验证和授权是两个关键的安全方面。Pundit的目标是为开发者...
数据集是科学研究与数据分析的重要资源,本数据集专注于高斯-埃尔米特正交规则,这是一种在数值积分中广泛使用的高效方法。高斯-埃尔米特规则是在无限区间(-∞,+∞)上,没有特定权重函数时进行积分计算的一种技术...
数据集是科学研究和数据分析的重要资源,本数据集专注于数值积分领域,特别关注在无穷区间(-∞,+∞)上采用高斯-埃尔米特正交规则进行积分的问题。高斯-埃尔米特正交规则是一种高效且精确的数值积分方法,尤其适用...