OO设计在语义或封装方面的优势是什么？ [英] Is OO design's strength in semantics or encapsulation?
问题描述
那么OOD的优势在哪里呢？相反，函数式编程将丰富性归因于动词而不是名词，因此封装和语义都是由方法而不是数据结构提供的。
我使用的是一个处于功能范围的系统，并且持续很长的OO的语义和封装。但是我可以看到面向对象的封装可能成为对对象进行灵活扩展的障碍。所以目前，我可以看到语义是一个更大的优势。
或者封装所有有价值的代码的关键？
编辑：我的意思是封装OO在这里提供的类型。 changeColor（door，blue）变成 door.changeColor（蓝色）。
您似乎在使用Encapsulation的狭义定义。假设您将封装定义为将数据与方法结合？，我是否正确？
如果我错了，请忽略本文的其余部分。
封装不是一个松散的术语;实际上，它是由国际标准化组织定义的。 ISO的开放分布式处理参考模型 - 定义了以下五个概念：
$ b $ p实体：任何感兴趣的具体或抽象的事物。
对象：实体的模型。一个对象的特征在于它的行为，以及它的状态是双重的。
行为（对象）：一组行为，发生。
接口：一个对象行为的抽象，该对象由该对象的一个子集交互以及一组关于它们何时可能发生的约束组成。
封装：包含在对象中的信息只能通过对象支持的接口进行交互才能访问的属性。
我们可以进一步提出一个不言自明的建议：由于通过这些接口可以访问某些信息，因此必须隐藏某些信息并且在该对象内不可访问。这种信息展示的性质被称为信息隐藏，Parnas认为模块应该被设计为隐藏可能会改变的困难决策和决策，定义如下：参见其中一篇优秀的计算论文：
http：//www.cs.umd .edu / class / spring2003 / cmsc838p / Design / criteria.pdf
重要的是要注意，它不仅是隐藏信息的数据：它是一些与对象相关的行为，很难或可能发生变化。
在你的文章中，你似乎在说OO和在函数式编程中源于数据管理，但至少根据ISO和Parnas，数据管理不是封装的关键。所以我不明白为什么函数式编程中的封装需要与OO中的封装有所不同。
此外，您在文章中提到函数式编程提供封装， ......通过方法而不是数据结构。我认为，这是一种规模上的差异，而不是绝对的。如果我使用对象这个词，而不是数据结构（再次，请让我知道我是否误解了），那么您似乎发现OO的封装是通过对象和函数式编程的封装。
然而，通过上面的ISO定义，一个对象就是我想要建模的任何东西。因此，类可以被封装在一个包中，只要这些类中的一些对包的接口（即包的公共类）有贡献并且一些是隐藏信息（包中的私有类）。
同样的道理，方法被封装在一个类中 - 一些方法是公有的，一些是私有的。你甚至可以把这个降低一点，并说McCabian的连续代码序列被封装在方法中。每个形成封装在封装区域内的节点的图形;所有这些图形成一个图形堆栈。因此函数式编程可以很好地封装在函数/文件级别，但是这与OO的方法/类图没有区别，并且与OO的类/包图本质上没有什么不同。
另请注意，单词Parnas使用上面的内容：change。信息隐藏涉及潜在的事件，例如未来难以改变的设计决策。你问OO的力量在哪里？好吧，封装无疑是面向对象的一个优势，但问题就变成了：封装的优势在哪里？而答案就是明确的变化之一：变更管理。特别是，封装减少了潜在的最大变化负担。
潜在耦合的概念在这里很有用。
耦合本身被定义为另一个计算优秀论文中由一个模块与另一个模块的连接建立的关联强度的度量：
http://www.research.ibm.com/journal /sj/382/stevens.pdf
正如文章所述，用最好的语言说：最大限度地减少模块之间的连接还可以最大限度地减少路径变化和错误会传播到系统的其他部分，从而消除灾难性的涟漪效应，其中一个部分的变化导致另一个部分的错误，需要在其他地方进行额外的更改，从而产生新的错误等。
b$ b
但是，如此处所定义的那样，有两个限制可以轻松提升编辑。首先，耦合不会测量模块内连接，而这些模块内连接可能会产生与模块间连接一样多的纹波效应（本文确定，聚合将内部模块关联起来元素，但是这不是根据定义耦合的元素之间的连接（即对标签或地址的引用）来定义的。其次，任何计算机程序的耦合是给定的，因为模块连接或;在耦合的定义中几乎没有涉及Parnas所说的潜在变化的管理。
这些问题在一定程度上通过电位耦合的概念得到了解决：可在程序的所有元素中形成的最大可能连接数。例如，在Java中，包中的包私有（默认访问者）类不能在其上形成连接（即没有外部类可以依赖它，尽管有反射），但包中的公共类可以对它有依赖性。这个公共类将有助于潜在的耦合，即使目前还没有其他类依赖于它 - 当设计发生变化时，类将来可能会依赖它。
要看封装的力量，考虑负担原则。负担原则有两种形式。
强大的形式表明，转换一组实体的负担是转化的实体数量的函数。弱形式表明，转换实体集合的最大潜在负担是转化实体的最大潜在数量的函数。
创建或修改任何软件的负担系统是创建或修改的类的数量的函数（在这里我们使用Classes，假设OO系统，并且关注类/包级别的封装;我们同样可以关心函数/文件级别的函数式编程）。 （请注意，负担是现代软件开发通常是成本，或时间或两者兼而有之。）
依赖于特定修改类的类比不依赖于类的类更有可能受到影响对修改过的类进行修改。
修改后的类可能带来的最大潜在负担是所有依赖它的类的影响。
减少对修改后的类的依赖性因此降低了其更新会影响其他类的可能性，从而减少该类可能施加的最大潜在负担。 （这只不过是对结构化设计的重新陈述）。
减少系统中所有类之间的最大潜在依赖数量减少了对特定类别的影响会导致其他类别更新的可能性，从而降低所有更新的最大潜在负担。
封装，通过降低最大潜力所有阶级之间的依赖关系数量，因此减轻了负担原则的薄弱形式。这一切都被封装理论所覆盖，它试图用数学方法证明这种断言，并使用潜在的耦合作为构建程序的逻辑手段。然而，请注意，当你问，封装所有有价值代码的关键？答案肯定是：不。所有有价值的代码都没有单一的密钥。在某些情况下，封装只是一种帮助提高代码质量的工具，以便它可能成为值得。
您还写道：封装可以成为物体灵活扩展的障碍。是的，它肯定可以：它确实被设计成阻碍扩展难以或可能改变的对象的设计决策的障碍。然而，这并不是一件坏事。另一种方法是将所有类别公开并且有一个程序表达它最大的潜在联结;但是负担原则的弱形式表明更新将变得越来越昂贵;这些是测量扩展障碍的成本。
最后，您将封装和语义进行有趣的比较，并且在您看来，OO的语义是它的更大的力量。我也不是语义学家（我甚至都不知道在拉姆齐先生的评论中提到它之前，这个词是否存在），但我认为你的意思是语义学，意思是意思，或者解释一个词的意思，基本上，一个带有woof（）方法的类应该被称为Dog。
确实有很大的优势这个语义。
对我来说，好奇的是你将语义与封装匹配并寻找一个胜利者;我怀疑你会找到一个。
在我看来，有两种激励封装的力量：语义和逻辑。 b $ b
语义封装仅仅意味着基于封装的节点含义（使用通用术语）进行封装。所以如果我告诉你我有两个包，一个叫'动物'，另一个叫'矿物'，然后给你三类Dog，Cat和Goat，并询问这些类应该封装在哪些包中，然后给定没有其他信息，你完全可以声称这个系统的语义会暗示这三个类被封装在动物包中，而不是矿物。
封装的另一个动机是逻辑，特别是上面提到的潜在耦合的研究。封装理论实际上提供了应该用来封装许多类的封装数量的等式，以便将潜在的耦合降至最小。
对于我来说，封装作为一个整体是这种语义和逻辑方法之间的折衷：如果这使得程序在语义上更容易理解，我会允许我的程序的潜在耦合超过最小值;但是巨大而浪费的潜在耦合水平将会是一个警告，即我的程序需要重新构造，不管它的语义如何明显。（如果好先生拉姆齐仍然在阅读，你或你的语义学家朋友能否给我一个更好的词来表达我在这里使用的语义学阶段？使用更恰当的术语将是一件好事。）
问候，
爱德。
Object-oriented design (OOD) combines data and its methods. This, as far as I can see, achieves two great things: it provides encapsulation (so I don't care what data there is, only how I get values I want) and semantics (it relates the data together with names, and its methods consistently use the data as originally intended).
So where does OOD's strength lie? In constrast, functional programming attributes the richness to the verbs rather than the nouns, and so both encapsulation and semantics are provided by the methods rather than the data structures.
I work with a system that is on the functional end of the spectrum, and continually long for the semantics and encapsulation of OO. But I can see that OO's encapsulation can be a barrier to flexible extension of an object. So at the moment, I can see the semantics as a greater strength.
Or is encapsulation the key to all worthwhile code?
Edit: I mean specifically the type of encapsulation OO provides here. changeColor(door,blue) becomes door.changeColor(blue).
You appear to be using a rather narrow definition of, "Encapsulation." Would I be right in presuming that you define encapsulation to be, "Combining data with methods?"
If I’m wrong then please ignore the rest of this post.
Encapsulation is not a loose term; in fact, it’s defined by the International Organisation for Standardization. The ISO’s Reference Model of Open Distributed Processing - defines the following five concepts:
Entity: Any concrete or abstract thing of interest.
Object: A model of an entity. An object is characterised by its behaviour and, dually, by its state.
Behaviour (of an object): A collection of actions with a set of constraints on when they may occur.
Interface: An abstraction of the behaviour of an object that consists of a subset of the interactions of that object together with a set of constraints on when they may occur.
Encapsulation: the property that the information contained in an object is accessible only through interactions at the interfaces supported by the object.
We can further make a self-evident proposal: as some information is accessible via these interfaces, some information must be hidden and inaccessible within the object. The property such information exhibits is called information hiding, which Parnas defined by arguing that modules should be designed to hide both difficult decisions and decisions that are likely to change, see one of the great computing papers:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
It’s important to note that it is not only the data that is information-hidden: it is some subset of behaviour associated with the object that is difficult or likely to change.
In your post, you seem to be saying that the difference between encapsulation in OO and in functional programming stems from data management, but at least according to the ISO and Parnas, data management is not the key to encapsulation. So I don’t see why encapsulation in functional programming need be any different from that in OO.
You mention, furthermore, in your post that functional programming provides encapsulation, "… by the methods rather than the data structures." This, I think, is a difference of scale rather than of absolute. If I use the word, "Object," rather than, "Data structure," (again, please let me know if I’m misinterpreting), then you seem to find significance in OO’s encapsulation by object and functional programming’s encapsulation by method.
Yet by the ISO definition above, an object is anything I wish to model. Thus classes may be encapsulated within a package, so long as some of those classes contribute to the package’s interface (i.e., the public classes of the package) and some are information-hidden (the private classes in the package).
By the same token, methods are encapsulated within a class – some methods being public and some private. You can even take this a notch lower and say that McCabian sequential sequences of code are encapsulated within methods. Each forms a graph of nodes encapsulated within encapsulated regions; and all these graphs form a graph stack. Thus functional programming may well encapsulated at the function/file level, but this is no different from the method/class graph of OO, and essentially no difference from the class/package graph of OO either.
Also, note that word Parnas uses above: change. Information hiding concerns potential events, such as the changing of difficult design decisions in the future. You ask where OO’s strength’s lie; well, encapsulation is certainly a strength of OO, but the question then becomes, "Where does encapsulation’s strength lie?" and the answer is one of resounding clarity: change management. Particularly, encapsulation reduces the maximum potential burden of change.
The concept of, "Potential coupling," is useful here.
"Coupling," itself is defined as, "A measure of the strength of association established by a connection from one module to another," in another of computing’s great papers:
http://www.research.ibm.com/journal/sj/382/stevens.pdf
And as the paper says, in words never since bettered, "Minimizing connections between modules also minimizes the paths along which changes and errors propagate into other parts of the system, thus eliminating disastrous, "Ripple," effects, where changes in one part cause errors in another, necessitating additional changes elsewhere, giving rise to new errors, etc."
As defined here, however, there are two limitations which can easily be lifted. Firstly, coupling does not measure intra-module connections, and these intra-module connections can give rise to just as many, "Ripple," effects as inter-module connections (the paper does define, "Cohesion," to relate intra-module elements, but this is not defined in terms of connections between elements (i.e., references to labels or addresses) with which coupling was defined). Secondly, the coupling of any computer program is a given, in that modules are connected or; there is little scope within the definition of coupling to manage the potential changes of which Parnas speaks.
Both these issues are resolved, to some degree, with the concept of potential coupling: the maximum possible number of connections formable among all elements of a program. In Java, for example, a class that is package-private (the default accessor) within a package cannot have connections formed on it (i.e., no outside classes can depend on it, reflection notwithstanding), but a public class within a package can have dependencies on it. This public class would contribute to the potential coupling even if no other classes depend on it at the moment – classes might depend on it in future, when the design changes.
To see encapsulation’s strength, consider the Principle of Burden. The Principle of Burden takes two forms.
The strong form states that the burden of transforming a collection of entities is a function of the number of entities transformed. The weak form states that the maximum potential burden of transforming a collection of entities is a function of the maximum potential number of entities transformed.
The burden of creating or modifying any software system is a function of the number of classes created or modified (here we use, "Classes," presuming an OO system, and are concerned with encapsulation at the class/package level; we could equally have concerned ourselves with the function/file level of functional programming). (Note that the, "Burden," is modern software development is usually cost, or time, or both.) Classes that depend on a particular, modified class have a higher probability of being impacted than classes that do not depend on the modified class.
The maximum potential burden a modified class can impose is the impacting of all classes that depend on it.
Reducing the dependencies on a modified class therefore reduces the probability that its update will impact other classes and so reduces the maximum potential burden that that class can impose. (This is little more than a re-statement of the, "Structured design," paper.)
Reducing the maximum potential number of dependencies between all classes in a system therefore reduces the probability that an impact to a particular class will cause updates to other classes, and thus reduces the maximum potential burden of all updates.
Encapsulation, by reducing the maximum potential number of dependencies between all classes, therefore mitigates the weak form of the Principle of Burden. This is all covered by, "Encapsulation theory," which attempts to mathematically prove such assertions, using potential coupling as the logical means of structuring a program.
Note, however, that when you ask, "Is encapsulation the key to all worthwhile code?" the answer must surely be: no. There is no single key to all worthwhile code. Encapsulation is, in certain circumstances, merely a tool to help improve the quality of code so that it may become, "Worthwhile."
You also write that, " … encapsulation can be a barrier to flexible extension of an object." Yes it most certainly can: it is indeed designed to be a barrier against extending the design decisions of an object that are difficult or likely to change. This is not, however, thought to be a bad thing. An alternative approach would be to have all classes public and have a program express its maximum potential coupling; but then the weak form of the Principle of Burden states that updates will become increasingly costly; these are the costs against which barriers to extension are to be measured.
Finally, you make the interesting comparison between encapsulation and semantics, and that, in your opinion, OO’s semantics are its greater strength. I’m no semanticist either (I didn’t even know such a word existed before the good Mister Ramsey alluded to it in his comment) but I presume you mean, "Semantics," in the sense of, "the meaning, or an interpretation of the meaning, of a word," and very basically that a class with a, woof() method should be called a Dog.
There is great strength indeed in this semantics.
What is curious to me is that you pit semantics against encapsulation and look for a winner; I doubt you’ll find one.
In my opinion, there are two forces that motivate encapsulation: the semantic and the logical.
Semantic encapsulation merely means encapsulation based on the meaning of the nodes (to use the general term) encapsulated. So if I tell you that I have two packages, one called, 'animal,' and one called 'mineral,' and then give you three classes Dog, Cat and Goat and ask into which packages these classes should be encapsulated, then, given no other information, you would be perfectly right to claim that the semantics of the system would suggest that the three classes be encapsulated within the, 'animal,' package, rather than the, 'mineral.'
The other motivation for encapsulation, however, is logic, and particularly the study of potential coupling, mentioned above. Encapsulation theory actually provides equations for the number of packages that should be used to encapsulate a number of classes in order to minimise the potential coupling.
For me, encapsulation as a whole is the trade-off between this semantic and logical approach: I’ll allow the potential coupling of my programs to rise above the minimum if this makes the program semantically easier to understand; but enormous and wasteful levels of potential coupling will be a warning that my program needs to be re-structured no matter how semantically obvious it is.
(And if the good Mister Ramsey is still reading, could you or your semanticist friends give me a better word for the, "Semantics," phase I’m using here? It would be good to use a more appropriate term.)
Regards, Ed.
这篇关于OO设计在语义或封装方面的优势是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
