Class Architecture

  • Thread starter Thread starter Techno_Dex
  • Start date Start date
T

Techno_Dex

I am using the Enterprise Library, specifically the Logging functionality.
I would like to write a class that has protected methods which perform the
actual logging of methods that are called and possibly raise events. My
problem is I'm struggling with the design. I want to design this
functionality in a fashion that I can be inherited by other classes (mainly
base classes) for both UI contol classes and non UI classes. I have looked
into the decorator pattern but this won't work as the inheritance of UI Base
Classes start to cause problems. Does anyone have any thoughts on solving
this?


public class MethodLogging
{
protected virtual void OnMethodRequestBegin(MethodRequestEventArgs e)
{
//Log the Method Name using verbose logging (i.e. e.MethodName)
//Raise an event to let other classes know a method was called
}

protected virtual void OnMethodRequestEnd (MethodRequestEventArgs e)
{
//Log the Method Name using verbose logging (i.e. e.MethodName)
//Raise an event to let other classes know a method was called
}
}

//Here is the problem, as C# doesn't allow multiple class inheritance
public class BaseUIClass : Form, MethodLogging
{
public void MethodA()
{
OnMethodRequestBegin (new MethodRequestEventArgs ("MethodA"));

//Do Work for Method A

OnMethodRequestEnd (new MethodRequestEventArgs ("MethodA"));
}
}

public class BaseClass : MethodLogging
{
public void MethodB()
{
OnMethodRequestBegin (new MethodRequestEventArgs ("MethodB"));

//Do Work for Method B

OnMethodRequestEnd (new MethodRequestEventArgs ("MethodB"));
}
}

I have thought about using Interfaces, but then I still have to code the
OnMethodRequestBegin and OnMethodRequestEnd for every single UI Control
which duplicates the code all over the place instead of keeping everything
in one nice neat package. I would like to come up with a solution that will
work for both UI and non UI classes alike.
 
What you're talking about is a business class, which presents no user
interface, but performs an operation. It should be in a class libary. Then
you can host it in any kind of application you want - no inheritance
necessary.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.
 
I agree with what you are saying but not sure I follow what you have in
mind. Are you suggesting that I make the business class with public static
methods and ignore the protected methods that might be used for event
handling? My main concerns here is I don't want to be putting duplicate
code all over the place as it is bad OO design. Say in the future that the
Enterprise Library removes the Logging functionality for some reason, I
don't want a bunch of static methods all over my code which become
worthless. Please explain your approach and possibly some scratch code.
 
That's not exactly what I'm saying. The typical event model is that a class
exposes events as public members, but fires them with private or protected
members, so that any class outside the class can subscribe to the events,
but only the class itself can raise them. As for static methods, I don't see
any particular reason why you would want to use static methods. Any class
you design can be instantiated as many times as you like. Static methods and
properties are another topic altogether. They are useful where they are
useful, and not useful where they are not useful. For example, the
System.Math class is composed (almost?) entirely of static methods, simply
because these methods do not interact with each other, but each performs an
atomic function and exits immediately, without affecting anything except the
return value of the method.

In fact, the Common Language Runtime Library is an assortment of classes of
many different types, all of which can be used in any application you write.
Some are static. Some have static methods. Most are not. I hope that clears
things up for you. Let me know if there's anything you don't understand
about what I'm saying.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.
 
I understand eactly what your talking about in this post, it's the first
post that I'm questioning. So you are basically advocating the
instantiation of a global class business object and calling Logging methods
on the business object? It seams much more eligant and easy to maintain if
there were so way to create the public events and protected methods that
launch those events (and at the same time log the methods that are called)
in a single class that can be inherited by all other classes instead of
creating public events and protected methods in every single class. That is
just duplication of code and bad OO design.
 
Back
Top