.NET abstract classes.

Question

I am designing a website navigation hierarchy. This is a tree of nodes.

Most sites are pages. Some sites are links (think of keyboard shortcuts in Windows).

Most pages contain HTML content. Some execute code.

I would like to introduce them as this set of classes and abstract classes (MustInherit) & hellip;

class diagram http://img396.imageshack.us/img396/1711/nodeclassinheritanceej0.gif

This is the database table where I am going to store all of this & hellip;

database table http://img178.imageshack.us/img178/8573/nodetablefm8.gif

Here where I am at a standstill. PageNodes may or may not be rooted.

How should I handle the root class?

class diagram http://img396.imageshack.us/img396/5758/rootclasshf9.gif

I do not want to have all four of & hellip;

• HtmlPageNode
• CodePageNode
• Html Root PageNode
• Code Root PageNode

I want the HtmlPageNode and CodePageNode classes to inherit from either PageNode or RootPageNode. Is it possible?

---

Clarification: there are several root nodes, and the roots may have parent nodes. Each of them is the root of only a subtree, which is distinguished by its excellent style. Think of different, colored departments. (Perhaps the root is a poor choice of name. Suggestions?)

---

Update: Regarding the name "Root" ...
I asked: Is there a specific name for the node that matches the subtree?

Answer 1

Use Composite Template .

---

As for your root nodes, are there differences in functionality or a difference in its appearance? If the difference is just the look, I suggest you link to a separate Style class from your PageNode.

If there are differences in functionality And you have many types of pages, consider using the Decorator Pattern .

Answer 2

As noted, a composite template may be a good solution.

If this does not work for you, it may be easier - if necessary - to define Root as an interface and apply it as necessary.

Of course, this does not allow you to provide an implementation of Root ...
If Root needs to have an implementation, you can use the Decorator pattern.

Answer 3

Actually, since the "root" node is a special case of node, you probably need RootHtmlPageNode: HtmlPageNode.

Another idea: since you are not indicating what the difference is between the “root” and the “normal” node, maybe just a flag in the node that determines whether it is root or not will also be a good design.

EDIT: According to your explanation, there is no functional difference between the normal and the root node, so a simple flag (or the IsRootNode property) is enough. If the "root" node provides only styling data (or any other data for yourself and your children), you can put this style data in a separate structure / class and render it recursively (based on IsRootNode):

class Node { private bool isRootNode; public bool IsRootNode; private StylingData stylingData; public StylingData StylingData { set { if (this.IsRootNode) this.stylingData = value; else throw new ApplicationException("The node is not root."); } get { if (this.IsRootNode) return this.stylingData; else return this.parent.StylingData; } } } 

This assumes that each node has a parent reference to it.

This is beyond the scope of the question since I do not know the exact design.

Answer 4

I want the HtmlPageNode and CodePageNode classes to inherit from either PageNode or RootPageNode. Is it possible?

Yes it is possible. You need the HtmlPageNode and codePageNode to have an object that will be an abstract class that will inherit PageNode and RootPageNode. In the constructor of HtmlPageNode and codePageNode, you accept your new abstract class, which will be PageNode or RootPageNode in your case. So you have 2 different classes with the same methods, but two different objects. Hope to help you!

Answer 5

Clarification: there are several root nodes, and the roots may have parent nodes. Each of them is the root of only a subtree, which is distinguished by its excellent style. Think of different, colored departments. (Perhaps the root is a poor choice of name. Suggestions?)

A root is a poor choice of name because it is (somewhat ironically) perceived as clearly the upper level of the tree structure, because the tree begins with the root coming out of the ground. Any node, besides this, is a branch or leaf and is not attached directly to the root.

The best name will look like IsAuthoritativeStyleNode, IsCascadingStyleNode, IsStyleParentNode or qualify it instead: for example. IsDepartmentRootNode. Providing clear, unambiguous names is one of the factors that greatly improves readability / ease of understanding.

You cannot achieve what you want only through abstract base classes / inheritance. As per other suggestions, consider interfaces instead.

I would also think that you allow too much database schema schema with your client side design. Not to say that in this case you need to change, but at least you need to think. Think about how you can decompose properties into separate tables that reference the common "Node" table and normalize them to minimize zeros and / or duplicate identical data.

Answer 6

Should the PageNode class simply have a property of type Root?

alt text http://img206.imageshack.us/img206/2968/rootpropertytygg0.gif

This contradicts the idea that the root PageNode is-a file. Or are they not "eat-root" because only some of them are roots?

And does this imply that a property can cross a tree looking for an ancestral root? Or is it just me?