Implementing a folder object?

**Colin Young** · Nov 16 '05, 01:45 AM

Re: Implementing a folder object?

I think the abstract folder method is the way to go. You cold provide an
enum on the abstract folder that would return the type of the derived
folder, but that would mean having to update the enum if you add a new
folder type. Not a big deal, but to me it is counter to clear coding.

Presumably the client code will be familiar with the types of folders it
knows how to process and you could just use the 'as' or 'is' operator to
test the type.

Colin

"Dave Veeneman" <davidv@nospam. com> wrote in message
news:OftHMd$FEH A.2208@TK2MSFTN GP09.phx.gbl...[color=blue]
> I'm puzzling over the best design for a Folder object.
>
> I have two basic domain objects; leat's call them an Apple and an Orange.
> The objects are maintained in separate hierarchies, and each hierarchy is
> organized by Folder objects. A Folder object can contain either Apples, or
> Oranges, or other Folders. A Folder contains only one type of object. For
> example, a Folder won't contain Apples and other Folders, or Apples and
> Oranges.
>
> What's the best design for the Folder object? I was going to use a GoF
> Composite pattern, but it doesn't really seem to fit, since a Folder is
> neither an Apple nor an Orange. At this point, I'm leaning toward an
> abstract Folder, from which I derive an AppleFolder and an OrangeFolder.[/color]
But[color=blue]
> I'm still puzzling over how clients tell whether a Folder contains other
> Folders or fruit objects.
>
> Any advice would be greatly appreciated. Thanks in advance.
>
> --
> Dave Veeneman
> Chicago
>
>[/color]

**Fitim Skenderi** · Nov 16 '05, 01:45 AM

Re: Implementing a folder object?

I think Composite pattern still applies here. Yes you are correct in saying
that apples are not oranges, and oranges/apples are not folders, but they
may have same ancestor. An analogy would be like
humans, dogs and mice, even though they are different they still are
mammals.

So following Composite pattern, your Orange and Apple objects would descend
from Leaf, whereas Folder object would descend from Composite object. You
could modify the Composite pattern in a way that you would remove Add/Remove
methods from the Component object and introduce them on Composite object, so
only Folder objects would have these methods. Then you could add an enum
property on Folder object which would tell you what type of objects the
Folder contains. Something like (following Composite pattern) :

public enum ObjectType
{
otOrange,
otApple,
otFolder
}

public abstract class MyComponent
{
private ObjectType myType;

public MyComponent()
{
}

protected void SetType(ObjectT ype aType)
{
myType = aType;
}

public ObjectType MyType
{
get { return myType; }
}
}

public abstract class Composite : MyComponent
{
public abstract void AddChild(MyComp onent aChild);
public abstract void RemoveChild(MyC omponent aChild);
public abstract MyComponent GetChild(int index);
}

public abstract class Leaf : MyComponent
{
...
}

public class Orange : Leaf
{
public Orange()
{
SetType(otOrang e);
}
...
}

public class Apple : Leaf
{
public Orange()
{
SetType(otLeaf) ;
}
...
}

public class Folder : Composite
{
private ObjectType mContainsType;
public Folder (ObjectType aType)
{
SetType(otFolde r);
mContainsType = aType;
}

public override void AddChild(MyComp onent aChild)
{
if(aChild.MyTyp e == mContainsType)
// add it to the collection
else
// throw an excpetion since the type is different
}

public abstract void RemoveChild(MyC omponent aChild)
{
...
}

public abstract MyComponent GetChild(int index)
{
...
}
}

Hope this helps

Fitim Skenderi

"Dave Veeneman" <davidv@nospam. com> wrote in message
news:OftHMd$FEH A.2208@TK2MSFTN GP09.phx.gbl...[color=blue]
> I'm puzzling over the best design for a Folder object.
>
> I have two basic domain objects; leat's call them an Apple and an Orange.
> The objects are maintained in separate hierarchies, and each hierarchy is
> organized by Folder objects. A Folder object can contain either Apples, or
> Oranges, or other Folders. A Folder contains only one type of object. For
> example, a Folder won't contain Apples and other Folders, or Apples and
> Oranges.
>
> What's the best design for the Folder object? I was going to use a GoF
> Composite pattern, but it doesn't really seem to fit, since a Folder is
> neither an Apple nor an Orange. At this point, I'm leaning toward an
> abstract Folder, from which I derive an AppleFolder and an OrangeFolder.[/color]
But[color=blue]
> I'm still puzzling over how clients tell whether a Folder contains other
> Folders or fruit objects.
>
> Any advice would be greatly appreciated. Thanks in advance.
>
> --
> Dave Veeneman
> Chicago
>
>[/color]

**Dave Veeneman** · Nov 16 '05, 01:45 AM

Re: Implementing a folder object?

Thanks. I had pretty much come to the same conclusion, because it makes
things much easier for the client. What I'm going to do is create composite
Apple and Orange objects. Each object will have a Children property, which
will be a collection of objects of the same type. If an Apple or Orange has
children, the client knows its a node, so it will display a folder icon and
ignore anything except the children. If the Apple or Orange has no children,
the client knows the object is a leaf, so it will display it as such.

**Fitim Skenderi** · Nov 16 '05, 01:45 AM

Re: Implementing a folder object?

OK. I missunderstood you and thought that only folders can contain children.
Anyway
good luck with your project

Fitim Skenderi

"Dave Veeneman" <davidv@nospam. com> wrote in message
news:ejDw8CAGEH A.2656@TK2MSFTN GP09.phx.gbl...[color=blue]
> Thanks. I had pretty much come to the same conclusion, because it makes
> things much easier for the client. What I'm going to do is create[/color]
composite[color=blue]
> Apple and Orange objects. Each object will have a Children property, which
> will be a collection of objects of the same type. If an Apple or Orange[/color]
has[color=blue]
> children, the client knows its a node, so it will display a folder icon[/color]
and[color=blue]
> ignore anything except the children. If the Apple or Orange has no[/color]
children,[color=blue]
> the client knows the object is a leaf, so it will display it as such.
>
>[/color]

**Dave Veeneman** · Nov 16 '05, 01:46 AM

Re: Implementing a folder object?

No, you didn't misunderstand. I revisited my original design and decided to
implement GoF Component pattern (sort of).

So, an Apple can be a fruit or it can act as a folder for other Apples. An
Apple has a 'Children' property. If Children.Count > 0, then the Apple is a
container for other Apples. Oranges work the same way.

The client loads Apples into a treeview. It simply traverses the topmost
Apples collection recursively. If an Apple object has children, the client
displays a folder icon and loads the children into sub-nodes. It checks each
child's Children property to determine whether the object is acting as a
container or a leaf (well, actually, a fruit <g>). If a child is a leaf,
then the client shows an Apple icon. Oranges work the same way.

Thanks again for your help.

**Dave Veeneman** · Nov 16 '05, 01:50 AM

Re: Implementing a folder object?

One final note-- I tried short-cutting the implementation of the GoF
Composite pattern by simply slapping a Children property onto my Apples and
Oranges classes. I ended up needing a lot of tangled code to keep straight
whether I was dealing with a folder or an item. So, I've gone back and
refactored to implement the pattern as suggested by the GoF in both classes.

The lesson I learned: The GoF patterns are held in high esteem for a reason.
They really are time-tested solutions to recurring problems. Short-cutting
them can easily lead to more refactoring down the road.

--
Dave Veeneman
Chicago

Implementing a folder object?

Implementing a folder object?

Comment

Comment

Comment

Comment

Comment

Comment