A mathematical proof of encapsulation, part I
in [OOP]
|
From: Ed Kirwan on 18 Oct 2007 20:01 Hi, folks, I wonder if I might ask for some help? I've developed some mathematical laws for encapsulation (for a tiny family of systems) but as I'm not in any research organisation, I can't effectively check archives to see whether my work is actually original, or whether someone's already been down this path. If you have a minute could you take a peek at the article below and let me know whether you've come across similar work before? The article's here: http://www.edmundkirwan.com/encap/intro.html Thanks for your time. -- ..ed www.EdmundKirwan.com - Home of The Fractal Class Composition
From: Mark Nicholls on 19 Oct 2007 05:30 On 19 Oct, 01:01, Ed Kirwan <IAmFrac...(a)hotmail.com> wrote: > Hi, folks, > > I wonder if I might ask for some help? > > I've developed some mathematical laws for encapsulation (for a tiny family > of systems) but as I'm not in any research organisation, I can't > effectively check archives to see whether my work is actually original, or > whether someone's already been down this path. > > If you have a minute could you take a peek at the article below and let me > know whether you've come across similar work before? > > The article's here:http://www.edmundkirwan.com/encap/intro.html > > Thanks for your time. > > -- > .ed > > www.EdmundKirwan.com- Home of The Fractal Class Composition I can't really comment because I don't really understand it...(I've got an MA in maths...so the maths and graphs bit doesn't scare me)...it's what it's being applied to I'm slightly confused about. Can you illuminate the introduction with an example, and then given that example demonstrate some of the definitions against it.
From: H. S. Lahman on 20 Oct 2007 10:56 Responding to Kirwan... > The article's here: > http://www.edmundkirwan.com/encap/intro.html Unfortunately, I have two problems with the article. The first is the dependence on namespaces. Namespaces are a syntactic issue for language design but they have little to do with the semantics of named entities within those spaces and, consequently, with complexity, cohesion, and other OOA/D issues related to encapsulation. That segues to my second problem. We employ OO problem space abstraction because most customer problem spaces tend to be poorly defined, ambiguous, and often have shifting perspectives on semantics based on context. I agree with Nicholls that key definitions are missing from the paper: what is a Node and what is an Edge? I believe that trying to define encapsulation in terms of call graph connectivity is futile. OO programs use encapsulation to provide better maintainability than procedural programs, yet their call graphs are notoriously more complex than those of corresponding procedural programs. OTOH, if one defines edges in terms of relationships, one essentially has a moving target for complexity because quite different relationships may be relevant in different problem contexts for the same underlying problem space entity. The real problem, though, is the notion of 'node'. The OO paradigm abstracts identifiable problem space entities as objects. One then encapsulates the implementations of their properties, but one has very little latitude in what the objects and their responsibilities are or how they are related to other objects. That is all driven by the problem space. IOW, one encapsulates /after/ one has decided what is needed to solve the problem in hand. So there are no mechanical rules to be applied to decide whether one should break up existing objects, redistribute existing responsibilities, or redefine existing logical relationships based on graph theory. The only way one can provide better encapsulation is by abstracting the problem space itself differently and creating a new graph. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Ed Kirwan on 31 Oct 2007 19:17 Mark Nicholls wrote: > > I can't really comment because I don't really understand it...(I've > got an MA in maths...so the maths and graphs bit doesn't scare > me)...it's what it's being applied to I'm slightly confused about. > > Can you illuminate the introduction with an example, and then given > that example demonstrate some of the definitions against it. Hi, Mark, Thanks for the suggestion. I've chalked up an object-oriented overview here: http://www.edmundkirwan.com/encap/example.html Hope it helps. -- ..ed www.EdmundKirwan.com - Home of the mathematical laws of encapsulation.
From: Ed Kirwan on 31 Oct 2007 19:34
H. S. Lahman wrote: > Responding to Kirwan... > >> The article's here: >> http://www.edmundkirwan.com/encap/intro.html > > Unfortunately, I have two problems with the article. The first is the > dependence on namespaces. Namespaces are a syntactic issue for language > design but they have little to do with the semantics of named entities > within those spaces and, consequently, with complexity, cohesion, and > other OOA/D issues related to encapsulation. Thanks for the suggestions. I didn't realise that I'd put such emphasis on name spaces; I've tried to clarify now, particularly in the example, that name spaces aren't germane to the theory, but some form of, "Capsule," into which classes can be put, is. Name spaces fit that bill, but they are not a necessary pre-condition. (Though I'm struggling to think of anything else into which classes are usually encapsulated.) > > That segues to my second problem. We employ OO problem space abstraction > because most customer problem spaces tend to be poorly defined, > ambiguous, and often have shifting perspectives on semantics based on > context. I agree with Nicholls that key definitions are missing from the > paper: what is a Node and what is an Edge? I was primarily thinking of a node being a class and an edge being a source-code dependency between classes. If class A uses methods or data from class B, then there is an edge from class A to class B. > > I believe that trying to define encapsulation in terms of call graph > connectivity is futile. Agreed, (runtime) call graphs don't sit well with encapsulation. > OO programs use encapsulation to provide better > maintainability than procedural programs, yet their call graphs are > notoriously more complex than those of corresponding procedural > programs. OTOH, if one defines edges in terms of relationships, one > essentially has a moving target for complexity because quite different > relationships may be relevant in different problem contexts for the same > underlying problem space entity. Agreed, different relationships may exist between classes in different problem contexts, yet this doesn't excuse those relationships from being examined with a view to complexity. If two systems essentially solve the same problem, yet one has more possible relationships between its classes than the other, then I would argue that the latter is more complex than the former. > > The real problem, though, is the notion of 'node'. The OO paradigm > abstracts identifiable problem space entities as objects. One then > encapsulates the implementations of their properties, but one has very > little latitude in what the objects and their responsibilities are or > how they are related to other objects. That is all driven by the problem > space. IOW, one encapsulates /after/ one has decided what is needed to > solve the problem in hand. So there are no mechanical rules to be > applied to decide whether one should break up existing objects, > redistribute existing responsibilities, or redefine existing logical > relationships based on graph theory. I also tried to emphasise the theoretical nature of the equations, and how the recommendations that can be drawn from them are more relevant to real design than the figures the equations actually produce. I fully agree that we should design classes based on the problem space rather than looking to graph theory to design them for us. I also agree that comprehensibility of solution is much more important than the solution's maximum possible complexity. What graph theory shows, however, is a means of evaluating a design with respect to its maximum possible complexity. And even if that complexity measurement is theoretical, the recommendations we can derive from that theory seem sound: namely, that encapsulating classes within name spaces yields a lower maximum complexity that leaving those classes unencapsulated. Banal, but at least now provable. > The only way one can provide better > encapsulation is by abstracting the problem space itself differently and > creating a new graph. Indeed. Thanks again for the feedback. > > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman > hsl(a)pathfindermda.com > Pathfinder Solutions > http://www.pathfindermda.com > blog: http://pathfinderpeople.blogs.com/hslahman > "Model-Based Translation: The Next Step in Agile Development". Email > info(a)pathfindermda.com for your copy. > Pathfinder is hiring: > http://www.pathfindermda.com/about_us/careers_pos3.php. > (888)OOA-PATH -- ..ed www.EdmundKirwan.com - Home of the mathematical laws of encapsulation. |