Code architecture opinion

I hall,

I need your opinion on what is best in the following case.

I h开发者_开发知识库ave a hierarchic 2 level events class from a website (A and B are base class), this is coded in a framework dll (let's name it "TheLib.dll") to be factorized and reuseable:

A

• A son 1
• A son 2
• ...

B

• B son 1
• B son 2
• ...

Then I need some external tools (console/wpf app) that will display the content of each of this events each time wich some different (part of properties) and specific formatting for a log for exemple. But I get the event with their base type: A or B, not the native end type.

A first approach is to code this into "TheLibe.dll" declare an interface with a specific toStringxxx method and assign it to every events A son * and B son *

I am not fan of this, as the code should be in the console app and not into the framework because it will not be used in any other external tool.

So I coded the string formatting directly into the console app by using a generic cast from a call to GetType()

Let me know if it is good or bad and why ?

Sinn'

If your console app can know about A and B and all the sub-types derived from them, there isn't really much wrong with using something like GetType() and doing your application specific formatting directly in the console app. Just understand this approach is not very scalable.

If however, A and B can continually be extended and your console app can never know about all the possible sub-types without rebuilding it, you are better off to provide either the toString() interface so each class can do its own formatting or a print() interface that you can pass some kind of output stream so you could format your output depending on the type of stream passed in (e.g. ostream derived class in C++, java.io.OutputStream derived class in Java, ...)