From: craigslist.jg on
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
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
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
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
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.