A mathematical proof of encapsulation, part I
in [OOP]
|
From: S Perryman on 8 Nov 2007 16:54 topmind wrote: > S Perryman wrote: TM>One could also call that "categorization". >>No, one cannot. >>Because categorisation is organisation based on a *criteria* . >>The categorisation is enforced on said criteria. > Technically, no. One can say that "all these things here are in > category Foo because I just felt like it." Define "feel like it" . Once you have done so, I have the means to assess the categorisation. > And, I'm sure those who > put things into classes and methods have some kind of criteria in > their mind. Almost nobody will agree that randomly cubby-holing stuff > by itself automatically makes it "good". I'm sure they do. But once again (the third time I make this) , encapsulation is ... ah once again saved me the typing ... see *IMMEDIATELY BELOW* . >>Encapsulation (once again) is an orthogonal concept. >>Because it is the ability to organise things into a whole, and >>reference/use that whole. No criteria is defined as to what should >>be allowed to be part of the whole. >>>(In categories, items can belong to more than one group.) >>Correct. > But is that a separator from 'encapsulation'? No. It is *orthogonal* . Go to your nearest dictionary, and learn what this word actually means. Then come back to me and (attempt to) continue the debate. TM>Relatedness can be highly subjective. >>Wrong. It can be highly objective (as evidenced by the many metrics out >>there) . > Pick your favorite. Communication cohesion. > Let's dissect it. Away you go (if you can understand it) . Regards, Steven Perryman
From: topmind on 8 Nov 2007 22:54 S Perryman wrote: > topmind wrote: > > > S Perryman wrote: > > TM>One could also call that "categorization". > > >>No, one cannot. > >>Because categorisation is organisation based on a *criteria* . > >>The categorisation is enforced on said criteria. > > > Technically, no. One can say that "all these things here are in > > category Foo because I just felt like it." > > Define "feel like it" . > Once you have done so, I have the means to assess the categorisation. Word games, eh? Let's change it a little and assume stuff if randomly cubby holed. > > > > And, I'm sure those who > > put things into classes and methods have some kind of criteria in > > their mind. Almost nobody will agree that randomly cubby-holing stuff > > by itself automatically makes it "good". > > I'm sure they do. But once again (the third time I make this) , > encapsulation is ... ah once again saved me the typing ... see > *IMMEDIATELY BELOW* . > > > >>Encapsulation (once again) is an orthogonal concept. > >>Because it is the ability to organise things into a whole, and > >>reference/use that whole. No criteria is defined as to what should > >>be allowed to be part of the whole. Please be clear on exactly how it differs from categorizing. Needing a reason to clump under a reference is not material. You made that up just to F with me. > > >>>(In categories, items can belong to more than one group.) > > >>Correct. > > > But is that a separator from 'encapsulation'? > > No. It is *orthogonal* . > Go to your nearest dictionary, and learn what this word actually means. > Then come back to me and (attempt to) continue the debate. > > > TM>Relatedness can be highly subjective. > > >>Wrong. It can be highly objective (as evidenced by the many metrics out > >>there) . > > > Pick your favorite. > > Communication cohesion. Okay. I'll get back to you on this. > > > > Let's dissect it. > > Away you go (if you can understand it) . > > > Regards, > Steven Perryman -T-
From: topmind on 8 Nov 2007 23:50 topmind wrote: > S Perryman wrote: > > topmind wrote: > > > > > S Perryman wrote: > > > > TM>One could also call that "categorization". > > > > >>No, one cannot. > > >>Because categorisation is organisation based on a *criteria* . > > >>The categorisation is enforced on said criteria. > > > > > Technically, no. One can say that "all these things here are in > > > category Foo because I just felt like it." > > > > Define "feel like it" . > > Once you have done so, I have the means to assess the categorisation. > > Word games, eh? Let's change it a little and assume stuff if randomly > cubby holed. (correction: should be "is", not "if".) > > TM>Relatedness can be highly subjective. > > > > >>Wrong. It can be highly objective (as evidenced by the many metrics out > > >>there) . > > > > > Pick your favorite. > > > > Communication cohesion. > > Okay. I'll get back to you on this. As promised: Wikipedia: Communication cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information). www.eli.sdsu.edu (cs535): Communication Cohesion: Operations of a module all operate upon the same input data set and/or produce the same output data First of all, let me say that a lot of the "Cohesion" definitions seem somewhat shoehorned under the label "cohesion". For example, one could arbitrarily define "Zebba Cohesion" as two modules that output the number 7. That is fairly objective, but does not necessarily say anything real about "Cohesion" itself. Second, "operate on the same data" is rather wide such as to be not very useful. These two calls operate on the same data: objectX = new lkjlkk(...); foo.bar.zap.boo(objectX, b, c , d); asdfasdf.asdfasdfsd.ehs(1, 2, objectX); I suppose you could call that a kind of "cohesion" if you really wanted to, but where does that get you? Couldn't you have selected a more substantial definition? I sense this is turning into yet another pedantic word game. (Nor can we objectively verify that the reason for the grouping is due to co-referencing a given item. We can only verify that two given items reference the same thing.) > > > > > > > > Let's dissect it. > > > > Away you go (if you can understand it) . > > > > > > Regards, > > Steven Perryman > > -T-
From: S Perryman on 9 Nov 2007 04:38 topmind wrote: > S Perryman wrote: SP>Because categorisation is organisation based on a *criteria* . SP>The categorisation is enforced on said criteria. TM>Technically, no. One can say that "all these things here are in TM>category Foo because I just felt like it." >>Define "feel like it" . >>Once you have done so, I have the means to assess the categorisation. > Word games, eh? Let's change it a little and assume stuff if randomly > cubby holed. 1. No pal, *YOU* are the ones playing word games. Coupled with your usual disingenuous attempts to avoid facing your ignorance/non-understanding of a concept. 2. You have been told umpteen times by me what I consider encapsulation to be. You have then tried to claim that encapsulation is the same as/similar to categorisation. You have been told that categorisation is an *orthogonal* concept. Rather than admit to the fact that you have (in time-honoured tradition) hit rock bottom, you still keep digging. You cannot find any dictionary or CS definition that vaguely relates encapsulation to categorisation. So it is *YOU* who have had to resort to things like "feel like it" . But again I have killed your ramblings stone-dead. Because "feel like it" *HAS* a definition. And no matter how weird or random the things that are subject it are, it nevertheless forms a *criteria* . And as you have been told umpteen times, categorisation requires a criteria. How nonsensical that criteria is or seems is a moot point. Encapsulation has no such criteria. Because it is about bringing things together as a *whole* , and then referencing/using that whole. Encapsulation does *not* define *why* particular things are chosen to be part of the whole. That is a *different* concept. > Please be clear on exactly how it differs from categorizing. Needing a > reason to clump under a reference is not material. Go to a dictionary. Go to Wikipedia. Go *somewhere* . Get the definitions for encapsulation/categorisation and put them side by side. If you can find some common ground in said definitions, come back here and give them for us to have a look at. We are open to being corrected. I contend that you will not find anything (a challenge) . Else admit that you have insufficient command of the english language to be able to understand the differences between the definitions of two words/terms. > You made that up just to F with me. Don't come to me boy and complain that you're now stuck in a deep hole you were foolish enough to dig in the first place. Regards, Steven Perryman
From: S Perryman on 9 Nov 2007 05:08
topmind wrote: > As promised: > Wikipedia: Communication cohesion is when parts of a module are > grouped because they operate on the same data (e.g. a module which > operates on the same record of information). > www.eli.sdsu.edu (cs535): Communication Cohesion: Operations of a > module all operate upon the same input data set and/or produce the > same output data > First of all, let me say that a lot of the "Cohesion" definitions seem > somewhat shoehorned under the label "cohesion". For example, one could > arbitrarily define "Zebba Cohesion" as two modules that output the > number 7. That is fairly objective, but does not necessarily say > anything real about "Cohesion" itself. Cohesion is about the degree of *relatedness* of artifacts. The first major definitions came from the Structured Programming era. Seven forms (although I consider two to be the same thing) are defined. The effects (of change) to s/w components exhibiting said forms are well-known. > Second, "operate on the same data" is rather wide such as to be not > very useful. These two calls operate on the same data: > objectX = new lkjlkk(...); > foo.bar.zap.boo(objectX, b, c , d); > asdfasdf.asdfasdfsd.ehs(1, 2, objectX); > I suppose you could call that a kind of "cohesion" if you really > wanted to Are the *definitions/implementations* of the boo and ehs ops in the same encapsulation entity (file, module, type, interface etc) ?? Depending on this, you have the answer as to whether you have communication cohesion. > Couldn't you have selected a more substantial definition? I did *NOT GIVE* those definitions. You found them *yourself* . So complain to yourself. > I sense this is turning into yet another pedantic word game. I sense you are close to hit rock bottom again ... > (Nor can we objectively verify that the reason for the grouping is due > to co-referencing a given item. We can only verify that two given > items reference the same thing.) We can verify whether anything (according to the definition) satisfies communication cohesion. We can also verify how far away something is (quantatively) from achieving communication cohesion. So, where is your "dissection" ?? What has it revealed to us ?? Regards, Steven Perryman |