Pitfalls of OOP
in [OOP]
|
Prev: Call for Papers & Sessions: The 2010 International Conference on Software Engineering Research and Practice (SERP'10), USA, July 2010
Next: Informatics 2010: submissions until 25 January 2010
From: Ed Kirwan on 3 Jan 2010 15:11 S Perryman wrote: > Ed Kirwan wrote: > > >> Encapsulation is about minimising the number of potential dependencies >> with the highest change-propagation probability, so that if you change >> the code in one place, you minimise the chance ripple-effect, forcing >> costly changes elsewhere. > > No, that's *coupling* . > > Encapsulation is about organising things into something that can be > *referenced as a whole* . Whether that whole is a module, ADT, class etc > is another story. > Sorry, I should have stated the definition of encapsulation that I used to make the above statement. The International Organisation for Standardization's Reference Model of Open Distributed Processing defines it as: "Encapsulation: the property that the information contained in an object is accessible only through interactions at the interfaces supported by the object." (Here, they also define, "Object," as, "The model of an entity," rather than the narrower, operationalist view of an object's being the instantiation of a class.) In 1972, Canadian David Parnas described how software should be designed using the technique of, "Information hiding,": "We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others." The point being that if functionality that might change is hidden, then changing this functionality will have a less burdensome impact than would be the case had that functionality been accessible to all other modules. Reading the encapsulation definition above, we see that if an object's information is accessible only via the object's interfaces, then the object itself must manifest two fundamentally different phenomena: that which is accessible to clients (the interfaces) and that which is not accessible to clients (the contained information). It is suggested that the ISO and Parnas definitions can be married by the proposal that the information which is not accessible to clients is information-hidden in the Parnasian sense. To the degree that behaviour may be information-hidden, potential changes to that behaviour propagate to other parts of the system with less probability than changes to behaviour that is not information-hidden. It was in this sense that I meant that encapsulation is about minimising the number of potential dependencies with the highest change-propagation probability. Coupling is the measure of the strength of association established by a connection from one module to another. Potential coupling (at least with respect to the classes discussed in the slideware) is potential number of dependencies between the classes of a system. So I'd say that the claim I made about encapsulation above is not a definition of coupling, but rather states that encapsulation helps minimise potential coupling. Still, "Encapsulation is about organising things into something that can be *referenced as a whole*," is a also a succinct distillation. -- www.EdmundKirwan.com - Home of encapsulation theory
From: S Perryman on 3 Jan 2010 16:39 Ed Kirwan wrote: > [ defs snipped but read and acknowledged ... ] Encapsulation and information hiding are orthogonal concepts. Encapsulation is an *enabling mechanism* for information hiding. When a user U uses a component C, and the usage forces U to be dependent on the (internal) implementation of C, there is said to be a *content coupling* relationship between U and C. Content coupling is one form of coupling relationship that can exist between components. Information hiding is a means of preventing content coupling. Regards, Steven Perryman
From: Ed Kirwan on 3 Jan 2010 18:32
BGB / cr88192 wrote: > > this is why I dislike "OOP", it is the whole "you know we are the holy > ones because we eat the right food and wear the right kind of hat" > mindset. > You are wise. Rarely are religious belief, consumption habit and headwear fashion indicators of cost-effective production. Minimising the potential cost of ripple-effect is, however, a good indicator of cost-effective production. When faced with dogmatic assertion, the wise man will ask for evidence. An alledged production benefit that cannot show objective evidence of its benefit is to be rejected. -- www.EdmundKirwan.com - Home of encapsulation theory |