views:

74

answers:

4

Hi,

I'm working on the exception handling layer for my application.

I have read few articles on interfaces and generics. I have used inheritance before quite a lot and I'm comfortable with in that area.

I have a very brief design that I'm going to implement:

public interface IMyExceptionLogger
{
   public void LogException();

   // Helper methods for writing into files,db, xml
}

I'm slightly confused what I should be doing next.

public class FooClass: IMyExceptionLogger
{

   // Fields
   // Constructors

}

Should I implement LogException() method within FooClass? If yes, than I'm struggling to see how I'm better of using an interface instead of the concrete class...

I have a variety of classes that will make a use of that interface, but I don't want to write an implementation of that interface within each class.

In the same time If I implement an interface in one class, and then use that class in different layers of the application I will be still using concrete classes instead of interfaces, which is a bad OO design...

I hope this makes sense.

Any feedback and suggestions are welcome.

Please notice that I'm not interested in using net4log or its competitors because I'm doing this to learn.

Thank you

Edit:

Wrote some more code. So I will implement variety of loggers with this interface, i.e. DBExceptionLogger, CSVExceptionLogger, XMLExceptionLogger etc. Than I will still end up with concrete classes that I will have to use in different layers of my application.

+1  A: 

Define an interface Logger and define as many concrete implementations as you want (implementing it).

Next use composition - each class that needs to log something should have a Logger injected into it (via ctor argument or a setter).

This sounds more natural to me.

Gishu
+2  A: 

You cannot avoid having concrete classes implementing IMyExceptionLogger. However, you can stop the classes that need to do exception logging from having dependencies on those concrete classes. That is what the interface is for. So you inject the logger as a dependency of all classes that need to use it:

class MyClass
{
    public MyClass(IMyExceptionLogger exceptionLogger)
    {
        ....
        exceptionLogger.LogException(e);
    }
}

You could also look into some IoC containers such as Unity to help you manage these dependencies more easily.

Mark Heath
Hey, thank you for the reply.This means that I will store an interface in one DLL and implementations of that interface in seperate DLLS. This way I'll have various layers referencing single interface layer. Is this correct?
vikp
yes, that would be a good way to do it.
Mark Heath
Thanks a lot! Really appreciate it.
vikp
+1  A: 

yes you have to implement LogException() method in the FooClass.

Advantage of interfaces in your case that you may create concrete type of the logger (FooClass, or DBExceptionLogger or so) and pass around only IMyExceptionLogger reference. So that all your classes which log info will be independet from concrete realization of logger.

Arseny
That makes perfect sense. Spasibo! (thx)
vikp
+1  A: 

You should use an interface say IExceptionLog. If concrete clases have much in common e.g. XmlLogger, SOAPLogger you can create a base class for those. In classes where you want to use the logger a member having type IExceptionLog(the interface) should be created. The value of this member is set using dependency injection. You can use if you want a IoC containter

Manu
Everything up to dependency injection makes perfect sense. I'm going to read the article you have provided to get a better idea of what you mean. Thank you!
vikp
I've looked through the list of dependency injection libraries but I think I need to research more to get an idea of what it is and how do I use it.
vikp
You're welcome :)
Manu
You can check this if you want http://weblogs.asp.net/sfeldman/archive/2008/02/14/understanding-ioc-container.aspx
Manu