Question

We have a modular MVVM application. One of the interfaces looks like below

public interface ILogger
{

    void ReportError(ErrorType type);
}

The ErrorType type looks like below

class ErrorType
{
  string Message;
  string Title;
  object Owner;
}

Note the type object. The module implementing ILogger interface just calls GetString() from this as it just needs the name of the calling module. It usage of object looks like a problem to me. We are developing a loosely coupled application and we are letting any object to be passed between modules?

The usage of justified as object being more flexible and guaranteed to give a type name as compared to a string which could result in a typo. Also the implemetor of the interface not doing anything other than calling GetString().

I request some advice. The usage of object looks to me like the modules dont know how to identify between themselves. Is it good design to use object like this?

I am thinking more in terms of

 class ErrorType
 {
      string Message;
      string Title;
      string ModuleName;
 }

Answer 1

Since string ModuleName is all what you need now just use it. It will force you to expose minimal amount information and other modules will not be able to cheat and try to base any decisions on type of Owner object.

In real code use properties (preferably read only on IErrorType interface) so it is easy to change implementation i.e. to compute ModuleName based on object passed in.