|
Prev: Call for Papers: World Congress on Engineering and Computer Science WCECS 2007
Next: Io Language?
From: craigslist.jg on 10 May 2007 11:42 Hi, Let's say I have an instance of ClassA, which has an instance variable holding a list of numbers as an array (for simplicity's sake). Let's call this instance variable, arrayA. Let's assume all instVars are public. Now, ClassB needs to have access to arrayA, and delete some members within the array. Based on OOP principles, what's the better / cleaner implementation for this? 1. Create a couple of instVars in ClassB: instVar1 : reference to ArrayA instVar2: new array keeping track of deleted members Within ClassA, instantiate ClassB, and set instVar1. When ClassB is done, within ClassA, delete members from arrayA based on instVar2. ClassA doStuff() classB = new ClassB classB.instVar1 = arrayA classB.compileRemovedItems() arrayA.removeAll(classB.instVar2) ClassB compileRemovedItems() instVar2 = setRemovedItems() 2. As in (1), create a couple of instVars, but instantiate the instVar1 within classB ClassA doStuff() classB = new ClassB classB.compileRemovedItems() arrayA.removeAll(classB.instVar2) ClassB compileRemovedItems() instVar1 = classA.arrayA instVar2 = setRemovedItems() 3. From ClassB, access arrayA directly, and remove the items there. ClassA doStuff() classB = new ClassB classB.compileRemovedItems() ClassB compileRemovedItems() instVar1 = classA.arrayA instVar2 = setRemovedItems() instVar1.removeAll(instVar2) With 1, classB has no dependencies on classA, but I have to keep on setting instVar1 at every point I need to call compileRemovedItems. With 2, classB sets instVar1 from classA so I save that extra step. 3 is even more dependent on classA, as it is accessing and modifying arrayA directly. Thanks for reading.
From: H. S. Lahman on 10 May 2007 17:12 Responding to Craigslist.jg... > Let's say I have an instance of ClassA, which has an instance variable > holding a list of numbers as an array (for simplicity's sake). Let's > call this instance variable, arrayA. Let's assume all instVars are > public. So arrayA is a collection class implementing the R1 relationship in 1 R1 * [ClassA] --------------- [Number] > Now, ClassB needs to have access to arrayA, and delete some members > within the array. If ClassB needs access to those same numbers, they can't be part of the ClassA implementation as a fundamental language data structure like an array. That's because anything in the ClassA implementation needs to be hidden from the outside world, so it would be invisible to ClassB. So you really have, at the OOA/D level: [CLassA] | 1 | | R1 | | * [Number] | * | | R2 | | 1 [ClassB] OTOH, making a number a first class object is a bit of overkill. So what one really wants is a bit more abstraction: [ClassA] | 1 | | R1 | | 1 [NumberList] + getNumber(entryID) // e.g., whatever + setNumber(entryID, value) // e.g., whatever | 1 | | R2 | | 1 [ClassB] Now [NumberList] is a reasonable first class object abstraction to which both [ClassA] and [ClassB] have references and those references instantiate the R1 and R2 relationships, respectively. Note that all this does is take arrayA out of the [ClassA] implementation and make it a peer class of both ClassA and ClassB. The only trickiness lies in referential integrity (i.e., instantiating the relationships as [ClassA] and [ClassB] objects are created). That mechanics will depend upon the specific problem in hand, but a "factory" objects can encapsulate those sorts of rules. ************* 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: Daniel T. on 10 May 2007 21:25 craigslist.jg(a)gmail.com wrote: > Let's say I have an instance of ClassA, which has an instance variable > holding a list of numbers as an array (for simplicity's sake). Let's > call this instance variable, arrayA. Let's assume all instVars are > public. First mistake. Why make such an assumption? > Now, ClassB needs to have access to arrayA, and delete some members > within the array. A particular object of ClassB, or the class itself? Are the members that ClassB deletes supposed to also be deleted in the list that the ClassA object has? > Based on OOP principles, what's the better / cleaner implementation > for this? If ClassB is not a peer to ClassA then I would likely have the ClassA object pass a reference to the array when it creates the ClassB object. Then let the ClassB object delete the numbers itself. This way, ClassB is in no way dependent on ClassA and can be used by any class that is willing and able to pass ClassB an array of numbers. The above can tend to obfuscate the code though. A better choice would be to have a ClassA object instantiate a ClassB object, and have the ClassB object manage the array of numbers. [ClassA]--->[ClassB]--->[ArrayA] Instead of: [ClassA]----->[ClassB] | | | | +->[ArrayA]<-+
From: squirrel on 11 May 2007 12:36 On May 10, 11:42 pm, craigslist...(a)gmail.com wrote: > Hi, > > Let's say I have an instance of ClassA, which has an instance variable > holding a list of numbers as an array (for simplicity's sake). Let's > call this instance variable, arrayA. Let's assume all instVars are > public. > > Now, ClassB needs to have access to arrayA, and delete some members > within the array. > > Based on OOP principles, what's the better / cleaner implementation > for this? > > 1. Create a couple of instVars in ClassB: > instVar1 : reference to ArrayA > instVar2: new array keeping track of deleted members > > Within ClassA, instantiate ClassB, and set instVar1. > When ClassB is done, within ClassA, delete members from arrayA based > on instVar2. > > ClassA doStuff() > > classB = new ClassB > classB.instVar1 = arrayA > classB.compileRemovedItems() > arrayA.removeAll(classB.instVar2) > > ClassB compileRemovedItems() > > instVar2 = setRemovedItems() > > 2. As in (1), create a couple of instVars, but instantiate the > instVar1 within classB > > ClassA doStuff() > > classB = new ClassB > classB.compileRemovedItems() > arrayA.removeAll(classB.instVar2) > > ClassB compileRemovedItems() > > instVar1 = classA.arrayA > instVar2 = setRemovedItems() > > 3. From ClassB, access arrayA directly, and remove the items there. > > ClassA doStuff() > > classB = new ClassB > classB.compileRemovedItems() > > ClassB compileRemovedItems() > instVar1 = classA.arrayA > instVar2 = setRemovedItems() > instVar1.removeAll(instVar2) > > With 1, classB has no dependencies on classA, but I have to keep on > setting instVar1 at every point I need to call compileRemovedItems. > > With 2, classB sets instVar1 from classA so I save that extra step. > > 3 is even more dependent on classA, as it is accessing and modifying > arrayA directly. > > Thanks for reading. If you just want to decouple the dependency of classA and classB, why not apply Vistor pattern.
From: Daniel T. on 11 May 2007 20:42 squirrel <qianli.hu(a)gmail.com> wrote: > If you just want to decouple the dependency of classA and classB, why > not apply Vistor pattern. I think that would be a little extreme in this case. Simply removing the back-pointer would be enough to do the job.
|
Next
|
Last
Pages: 1 2 3 Prev: Call for Papers: World Congress on Engineering and Computer Science WCECS 2007 Next: Io Language? |