Re: Class Architecture by Techno_Dex
Techno_Dex
Fri Sep 22 08:45:47 CDT 2006
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.
"Kevin Spencer" <uce@ftc.gov> wrote in message
news:%23kUY%23hd3GHA.3516@TK2MSFTNGP06.phx.gbl...
> 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.
>
> "Techno_Dex" <nospamchurst@osi-corp.com> wrote in message
> news:uGa0DAc3GHA.4972@TK2MSFTNGP03.phx.gbl...
>>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.
>>
>>
>> "Kevin Spencer" <uce@ftc.gov> wrote in message
>> news:e8vl$Ub3GHA.5040@TK2MSFTNGP02.phx.gbl...
>>> 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.
>>>
>>> "Techno_Dex" <nospamchurst@osi-corp.com> wrote in message
>>> news:uMR75iZ3GHA.1252@TK2MSFTNGP04.phx.gbl...
>>>>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.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>