5.3 OBJECT-BASED DECOMPOSITION
5.3 基于对象的分解
The case for using objects (or more precisely, as seen below, object types) as the key to system modularization is based on the quality aims defined in chapter 1, in particular extendibility, reusability and compatibility.
使用对象(或如下所示,更精确地说是对象类型(object types))作为系统模块化的关键,这建立在第1章中所定义的品质目标之上,尤其是扩充性,复用性和兼容性.
The plea for using objects will be fairly short, since the case has already been made at least in part: many of the arguments against top-down, function-based design reappear naturally as evidence in favor of bottom-up, object-based design.
由于这种情况至少部份被建立了,所以使用对象的请求将会相当的快: 许多不支持由上而下的,基于函数设计的理由会很自然地重现了支持由下而上的,基于对象设计的迹象.
This evidence should not, however, lead us to dismiss the functions entirely. As noted at the beginning of this chapter, no approach to software construction can be complete unless it accounts for both the function and object parts. So we will need to retain a clear role for functions in the object-oriented method, even if they must submit to the objects in the resulting system architectures. The notion of abstract data type will provide us with a definition of objects which reserves a proper place for the functions.
然而,这种现象不应该让我们完全地放弃函数.如本章开始所述,对于软件构造来说,没有什么方法是完善的,除非它解决了函数和对象两者之间的关系.因此我们需要在面向对象的方法中保留一个明确的角色给函数,即使它们必须服从在目标系统架构中的对象.抽象数据类型的观念将会给我们提供一个对象的定义,这个对象为函数保留了一个适当的位置.
Extendibility
扩充性
If the functions of a system, as discussed above, tend to change often over the system’s life, can we find a more stable characterization of its essential properties, so as to guide our choice of modules and meet the goal of continuity?
如上所述,如果一个系统的函数试图时常改变系统的活动,我们能找到其本质属性中的一个更稳定的特征,以指导我们对模块的选择并符合连续性的目标吗?
The types of objects manipulated by the system are more promising candidates. Whatever happens to the payroll processing system used earlier as an example, it likely will still manipulate objects representing employees, salary scales, company regulations, hours worked, pay checks. Whatever happens to a compiler or other language processing tool, it likely will still manipulate source texts, token sequences, parse trees, abstract syntax trees, target code. Whatever happens to a finite element system, it likely will still manipulate matrices, finite elements and grids.
被系统操纵的对象类型是较有希望的备选方案.无论在先前所用的薪资处理系统例子上发生什么变化,它或许仍旧将操纵对象来描述雇员,薪水标准,公司规章,工时,薪资账单.无论在一个编译器或其它语言的处理工具上发生什么变化,它或许仍旧操纵着源代码,令牌顺序,剖析树,抽象语法树,目标码.无论在一个有限元系统上发生了什么变化,它或许仍然操纵着矩阵(matrices),有限元(finite elements)和网格.
This argument is based on pragmatic observation, not on a proof that object types are more stable than functions. But experience seems to support it overwhelmingly.
这个论据以实际的调查为基础,并没有证明对象类型比函数更稳定.但是经验却压倒性地支持了这个观点.
The argument only holds if we take a high-level enough view of objects. If we understood objects in terms of their physical representations, we would not be much better off than with functions — as a matter of fact probably worse, since a top-down functional decomposition at least encourages abstraction. So the question of finding a suitably abstract description of objects is crucial; it will occupy all of the next chapter.
如果我们以足够高的层次来观察对象,这个观点只是很合理.如果我们按照它们的实际表现来理解对象,我们并不能得到比函数更好的结果－事实上或许更糟,因为一个由上而下的函数分解至少还鼓励抽象化.因此,至关重要的问题是发现一个对象的合适的抽象描述；下一章的整个篇幅都会来讨论它.
Reusability
复用性
The discussion of reusability pointed out that a routine (a unit of functional decomposition) was usually not sufficient as a unit of reusability.
复用性的讨论指出一个例程(一个函数分解的单元)作为一个复用性单元通常是不充份的.
The presentation used a typical example: table searching. Starting with a seemingly natural candidate for reuse, a searching routine, it noted that we cannot easily reuse such a routine separately from the other operations that apply to a table, such as creation, insertion and deletion; hence the idea that a satisfactory reusable module for such a problem should be a collection of such operations. But if we try to understand the conceptual thread that unites all these operations, we find the type of objects to which they apply — tables.
表示法曾用了一个典型的例子: 表查询. 一个查询例程,以一个表面上的潜在需求开始,注意到我们不能够简单地复用这样的一个例程,把它从应用于表的运算,如创建,插入和删除这样的运算中分开;因此,对这样的一个问题,一个能满足复用模块的想法应该是这些运算的一个集合(collection). 但是如果我们试着其理解概念上的思路,即把所有的这些运算联合起来,那么我们就能找到应用的对象类型－表.
Such examples suggest that object types, fully equipped with the associated operations, will provide stable units of reuse.
这样的例子建议,完全具备相关运算的对象类型将会提供稳定的复用单元.
Compatibility
兼容性
Another software quality factor, compatibility, was defined as the ease with which software products (for this discussion, modules) can be combined with each other.
另一个软件品性因素,兼容性,被定义为对任一软件产品(在这个讨论中是指模块)易于彼此连接.
It is difficult to combine actions if the data structures they access are not designed for that purpose. Why not instead try to combine entire data structures?
如果它们访问的数据结构并不是为上述目的而设计的,那么联合这些动作是很困难的.为什么不去试着连接整个的数据结构?
5.4 OBJECT-ORIENTED SOFTWARE CONSTRUCTION
We have by now accumulated enough background to consider a tentative definition of object-oriented software construction. This will only be a first attempt; a more concrete definition will follow from the discussion of abstract data types in the next chapter.
此时,我们已经积累了充足的背景知识来试着考虑面向对象软件构造的定义.这将只是一种最初的尝试；在下一章的抽象数据类型的讨论中,我们会得出一个更精确的定义.
|
Object-oriented software construction (definition 1) Object-oriented software construction is the software development method which bases the architecture of any software system on modules deduced from the types of objects it manipulates (rather than the function or functions that the system is intended to ensure). 面向对象软件构造是一种软件开发方法,使用此方法的任何软件系统的架构都是基于从自己操纵的对象类型(而不是函数或系统规定好的的函数)中所推导出来的模块.
|
此方式的一个非正式的描述被面向对象的设计者奉为箴言:
|
OBJECT MOTTO Ask not first what the system does: Ask what it does it to! 不要先问系统做什么,而问系统如何去做它! |
To get a working implementation, you will of course, sooner or later, have to find out what it does. Hence the word first. Better later than sooner, says object-oriented wisdom. In this approach, the choice of main function is one of the very last steps to be taken in the process of system construction.
当然,得到一个能运行的实现,您终究会发现它所做的目的.单词first由此而来.迟来比早来更好,这说明了面向对象的聪明之处.在这个方法中,主函数的选择是系统结构过程中所采取的最终步骤之一.
The developers will stay away, as long as possible, from the need to describe and implement the topmost function of the system. Instead, they will analyze the types of objects of the system. System design will progress through the successive improvements of their understanding of these object classes. It is a bottom-up process of building robust and extendible solutions to parts of the problem, and combining them into more and more powerful assemblies — until the final assembly which yields a solution of the original problem but, everyone hopes, is not the only possible one: the same components, assembled differently and probably combined with others, should be general enough to yield as a byproduct, if you have applied the method well and enjoyed your share of good luck, solutions to future problems as well.
可能的话,开发者并不会参与从需求到描述和实现系统的顶端函数的过程.他们更可能的是去分析系统的对象类型.通过他们对这些对象类型的理解的持续的改进,系统设计将不断地前进.对局部的问题构建健壮和可扩充的解决方案,这是一个由下而上的过程,并且把它们合并进越来越强大的整合中－直到产生最初问题的解决方案的最终整合,但是每个人所希望的不仅仅如此:如果您已经把此方法应用得很好并且幸运的是解决方案也能应对将来的问题,那么这些组件,被不同地组合同时联合其它的组件,将能足够通用以产生另外的产品.
For many software people this change in viewpoint is as much of a shock as may have been for others, in an earlier time, the idea of the earth orbiting around the sun rather than the reverse. It is also contrary to much of the established software engineering wisdom, which tends to present system construction as the fulfillment of a system’s function as expressed in a narrow, binding requirements document. Yet this simple idea — look at the data first, forget the immediate purpose of the system — may hold the key to reusability and extendibility.
对于许多软件工程师来说,这个观点的改变所产生的震动就像先前地球围绕太阳转的思想对于传统想法的冲击一样.它也和以往所建立的软件工程的知识相反,在一个有限的约束性的需求文档中,旧观点倾向于用一个系统函数的实现来表现系统构造.这个简单的思维－先看数据,忽略系统的直接目的－也可以掌握复用性和扩充性的关键。
5.5 ISSUES
5.5 议题
The above definition provides a starting point to discuss the object-oriented method. But besides providing components of the answer it also raises many new questions, such as:
• How to find the relevant object types.
• How to describe the object types.
• How to describe the relations and commonalities between object types.
• How to use object types to structure software.
上述的定义对讨论面向对象方法提供了一个开端.但是除了提供对应的组件之外,它也引发了许多新的问题:
· 该如何寻找有关的对象类型.
· 该如何描述对象类型.
· 该如何描述在对象类型之间的关系和共通性.
· 该如何使用对象类型构建软件.
The rest of this book will address these issues. Let us preview a few answers.
本书的其余部分将会致力于这些议题.让我们先了解部分答案.
Finding the object types
寻找对象类型
The question “how shall we find the objects?” can seem formidable at first. A later chapter will examine it in some detail (in its more accurate version, which deals with object types rather than individual objects) but it is useful here to dispel some of the possible fears. The question does not necessarily occupy much of the time of experienced O-O developers, thanks in part to the availability of three sources of answers:
"我们将如何寻找对象?"这个问题起先看上去非常令人生畏.稍后的章节将会在一些细节上(在更精确的版本中,它处理对象类型而不是单独的对象)加以阐述但是这里先消除一些可能的疑惑.这个问题不会占据富有经验的OO开发者的太多时间,部份地原因是答案的三个来源的有效性:
• Many objects are there just for the picking. They directly model objects of the physical reality to which the software applies. One of the particular strengths of object technology is indeed its power as a modeling tool, using software object types (classes) to model physical object types, and the method’s inter-object-type relations (client, inheritance) to model the relations that exist between physical object types, such as aggregation and specialization. It does not take a treatise on object-oriented analysis to convince a software developer that a call monitoring system, in a telecommunications application, will have a class CALL and a class LINE, or that a document processing system will have a class DOCUMENT, a class PARAGRAPH and a class FONT.
在那里许多对象仅仅是为了选择.它们直接地模拟软件所应用的实际的对象.对象技术的特别力量之一是作为一个建模工具的真正能力,就是使用软件对象类型(类)去模拟实际的对象类型,使用函数的内部对象类型关系(客户端,继承)去模拟实际的对象类型之间存在的关系,像是集合(aggregation)和特殊化(specialization)之间的关系.在一个通讯应用程序中的一个呼叫监听系统将会有一个CALL类和一个LINE类,或一个文件处理系统将会有一个DOCUMENT类，一个PARAGRAPH类和一个FONT类,这并不需要用面向对象分析上的专题论文才能使软件开发者相信.
• A source of object types is reuse: classes previously developed by others. This technique, although not always prominent in the O-O analysis literature, is often among the most useful in practice. We should resist the impulse to invent something if the problem has already been solved satisfactorily by others.
对象类型的一个来源是复用:之前的类都是其他人开发的.虽然这并不总是在OO分析的文献中被强调,但是这种技术在实践中往往是最有用的.如果问题已经圆满地被其他人解决了,我们应该忍得住重新开发的冲动.
• Finally, experience and imitation also play a role. As you become familiar with successful object-oriented designs and design patterns (such as some of those described in this book and the rest of the O-O literature), even those which are not directly reusable in your particular application, you will be able to gain inspiration from these earlier efforts.
最后,经验和模仿也起着作用.当您熟悉了成功运用面向对象设计和设计模式(本书会介绍一部分,其余的会在OO文献中找到)时,甚至在您的个别的应用程序中还不可以直接复用的时候,你就能够从这些早期地努力中获得灵感.
We will be in a much better position to understand these object-finding techniques and others once we have gained a better technical insight into the software notion of object — not to be confused with the everyday meaning of the word.
一旦我们获得一个更佳的技术来洞察软件的对象观念－不要被这些词组的平凡意义所困扰,我们将能更好的理解这些探索对象和与之相关的技术.
Describing types and objects
描述类型和对象
A question of more immediate concern, assuming we know how to obtain the proper object types to serve as a basis for modularizing our systems, is how to describe these types and their objects.
一个更值得注意的问题是,假定我们知道该如何获得适当的对象类型作为我们的系统模块化的基础,该如何描述这些类型和它们的对象.
Two criteria must guide us in answering this question:
要回答这个问题,我们必须遵循二个标准:
• The need to provide representation-independent descriptions, for fear of losing (as noted) the principal benefit of top-down functional design: abstraction.
需要提供表示法独立的描述,这是担心失去由上而下函数设计的主要优点:抽象化.
• The need to re-insert the functions, giving them their proper place in software architectures whose decomposition is primarily based on the analysis of object types since (as also noted) we must in the end accommodate both aspects of the object-function duality.
需要重新插入(re-insert)函数,这是在主要地以对象类型分析为分解基础的软件架构中,提供给它们适当的位置,因为最终我们必须调节对象-函数二元性双方.
The next chapter develops an object description technique achieving these goals.
下一章我们将开发一个对象描述的技术用来完成这些目标.
Describing the relations and structuring software
描述关系并构建软件
Another question is what kind of relation we should permit between object types; since the modules will be based on object types, the answer also determines the structuring techniques that will be available to make up software systems from components.
另一个问题是我们应该在对象类型之间允许什么样的关系；由于模块以对象类型为基础,答案也决定了其构成技术,这种技术能有效的从组件中组合软件系统.
In the purest form of object technology, only two relations exist: client and inheritance. They correspond to different kinds of possible dependency between two object types A and B:
在最纯粹的对象技术形式中,只有二个关系存在: 客户端和继承.它们符合在二种对象类型A和B之间的可能存在的不同种类的相关性:
• B is a client of A if every object of type B may contain information about one or more objects of type A.
如果每个B类型的对象可以包含一个或更多的A类型对象的信息,那么B就是A的客户端.
• B is an heir of A if B denotes a specialized version of A.
如果B表示为一个特殊化的A版本,那么B就是A的一个继承.
Some widely used approaches to analysis, in particular information modeling approaches such as entity-relationship modeling, have introduced rich sets of relations to describe the many possible connections that may exist between the element of a system. To people used to such approaches, having to do with just two kinds of relation often seems restrictive at first. But this impression is not necessarily justified:
一些被广泛使用的分析方法,特别是信息建模方法如实体-关系建模(entity-relationship modeling),已经介绍了大量的相关机制来描述许多可能存在于系统元素之间的关联.在人们使用这样的方法之前,不得不首先处理二种看上去受限制的关系类型.但是这种印象不必证实:
• The client relation is broad enough to cover many different forms of dependency. Examples include what is often called aggregation (the presence in every object of type B of a subobject of type A), reference dependency, and generic dependency.
客户端的关系应足够宽广以包括许多不同形式的关联。例子包括有聚合(A类型的一个子对象,即B类型的每个对象的集合)，引用关联和泛型关联。
• The inheritance relation covers specialization in its many different forms.
继承关系包括了其许多不同形式的特殊化。
• Many properties of dependencies will be expressed in a more general form through other techniques. For example, to describe a 1-to-n dependency (every object of type B is connected to at least one and at most n objects of type A) we will express that B is a client of A, and include a class invariant specifying the exact nature of the client relation. The class invariant, being expressed in the language of logic, covers many more cases than the finite set of primitive relations offered by entity-relationship modeling or similar approaches.
关联的许多属性通过其它的技术将会以一种更通用的形式表达出来.举例来说,要描述一个1-to-n(一对多)的关联(B类型的每个对象至少被连接到一个或最多n个A类型的对象上)我们将表示B是一个A的客户端,同时包括一个类不变式(class invariant)来叙述客户端关系的精确类型。相比实体-关系建模或相似的方法提供的原始关系的有限集合,在逻辑语言中表达的类不变式包含了更多的情况。
5.6 KEY CONCEPTS INTRODUCED IN THIS CHAPTER
5.6 摘要
• Computation involves three kinds of ingredient: processors (or threads of control), actions (or functions), and data (or objects).
计算包括三种成分: 处理器(或控制线程),动作(或函数)和数据(或对象).
• A system’s architecture may be obtained from the functions or from the object types.
一个系统的架构可以从函数上或从对象类型上获得.
• A description based on object types tends to provide better stability over time and better reusability than one based on an analysis of the system’s functions.
基于对象类型的描述比基于系统函数分析的描述能提供更好的超时稳定性和更好的复用性.
• It is usually artificial to view a system as consisting of just one function. A realistic system usually has more than one “top” and is better described as providing a set of services.
通常人为的把一个系统看成只有一个函数所组成.一个现实的系统通常有超过一个的”顶端”,而且会提供一组服务来更好地描述此系统.
• It is preferable not to pay too much attention to ordering constraints during the early stages of system analysis and design. Many temporal constraints can be described more abstractly as logical constraints.
在系统分析和设计的早期阶段,较好的方法是不要对次序约束给予太多的关注.许多时间约束可能被更抽象的描述成逻辑限制。
• Top-down functional design is not appropriate for the long-term view of software systems, which involves change and reuse.
从一个包括变化和复用的软件系统的长期观点来看,由上而下的函数设计并不适宜.
• Object-oriented software construction bases the structure of systems on the types of objects they manipulate.
面向对象的软件构造把系统结构建立在其操纵的对象类型之上.
• In object-oriented design, the primary design issue is not what the system does, but what types of objects it does it to. The design process defers to the last steps the decision as to what is the topmost function, if any, of the system.
在面向对象的设计中,主要的设计议题不是系统做什么,而是系统有什么样的对象类型去做.如有可能,设计过程推迟到最后的阶段去决定什么是系统的最高点函数.
• To satisfy the requirements of extendibility and reusability, object-oriented software construction needs to deduce the architecture from sufficiently abstract descriptions of objects.
为了要满足扩充性和复用性的需求,面向对象软件构造需要从充份的对象抽象描述中推论出架构.
• Two kinds of relation may exist between object types: client and inheritance.
二种类型的关系可以在对象类型之间存在: 客户端和继承.
159
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
