• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 446
  • Last Modified:

Inheritance

HI Experts

We have a .NET application (VS 2008) that uses the Factory and Command Patterns to generate & invoke commands. Commands are logged, may have or not have timer support and are classified to categories which are also hierarchical (i.e. in category A you have commannd A1 and command A11 that is inherited from command A1 and so on...)

The difficulty with this is debug, since there are about 7 levels in the hierarchy , it takes time to navigate   and find the problem origin.

Questions :

1) When I did OO courses, I remember that they strongly recommended not to pass the 3 object hierarchy depth , is that true?

2) What design alternatives can you recommend in order to make our commands hierarchy shorter ?

Thanks
cmd.JPG
0
elimesika
Asked:
elimesika
  • 2
  • 2
1 Solution
 
mastooCommented:
1) One of my favorite books:
  "Heuristic 5.4 In theroy, inheritance hierarchies should be deep - the deeper, the better.
  Heruistic 5.5 In practice, inheritance hierarchies should be no deeper than an average person can keep in his or her short-term memory.  A popular value for this depth is six."  I must be more feeble minded than most as I like 3.

2) I can't read the jpg but it looks like you might be suffering a class explosion.  The command pattern purpose is to encapsulate requests, hiding implementation from the caller.  Possibly a narrower command hierarchy using classes representing individual functionality within a command and then aggregating functionality via Mediator pattern.
0
 
elimesikaAuthor Commented:
HI

Thanks for your respond.
Given that all commands are isolated and have no commnad-to-command commun ication, it seems that the mediator pattern will not help to simplify this.

Is there a way to use interfaces when applicable instead of classes in the inheritance tree to shorten the depth of the inheritance tree ???

0
 
mastooCommented:
I meant that you'd have a smaller number of command classes, and when they are constructed they get different components added.  I was thinking the mediator within the command would orchestrate those pieces, but on second thought that would be overkill.

For instance, during construction the factory feeds the command constructor a CLogger.  CLogger might be a base class reference to a CLogPrinter or CLogFile.  I'm not sure if this example applies to your case but it would be one less dimension for the command hierarchy and it helps with another golden rule: A class should capture one and only one key abstraction (i.e., a command shouldn't have to worry about implementation of logging).
0
 
elimesikaAuthor Commented:
Thanks
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now