Covers topics on the Microsoft Certification Exam for the .NET Framework (Exam 70-536, Microsoft .NET Framework - Application Development Foundation)

Monday, October 20, 2008

Implemeting the IConfigurationSystem Interface

After a long hiatus... getting back in the writing zone....

Within the "Embedding configuration, diagnostic, management, and installation features into a .NET Framework application" section of Exam 70-536 we are instructed to "Implement IConfigurationSystem Interface".

This seemed like a fairly straight forward task so I immediately looked up the interface in the MSDN docs. However, upon reading about the interface, I think someone goofed. The documentation specifically says that the IConfigurationSystem Interface "
supports the .NET Framework infrastructure and is not intended to be used directly from your code."

So maybe we don't need to know too much about this interface after all. Just in case the error is on the side of the documentation, you need to implement two methods to support the IConfigurationSystem Interface
  • GetConfig
  • Init

GetConfig returns an object and takes configKey (String) as a parameter.
Init returns void and takes no parameters.

Additional Resources
IConfigurationSystem Interface (Microsoft)


D-Train said...

All interfaces will "support the .NET framework" but cannot be used directly. Sometimes there are implementations provided with the interfaces (such as IList and List) and sometimes it's up to the developer. Just create a new class, implement the given interface (let Visual Studio create the signatures for you) and just "fill in the blanks." Then write a tester app to call upon your code. That's the whole point of interfaces: contractually agreed-upon class definition, not implementation-level specifics. Let's not forget that we use interfaces primarily to make it easier to pass objects around without being limited to specific implementations (eg, pass a DbCommand object instead of SqlCommand or OracleCommand). This is a major part of abstraction in object-oriented development.

wizkid said...

Thanks for the comment D-Train. I understand what you are saying, you described the use and need for interfaces in a nutshell.

However, how I read the docs is that this contract (interface) is one that while public was not really meant to be used by the general masses.

It was included by the .NET team to follow good OOO practices, but was not meant to be an interface that is widely used.

Because an interface is ALWAYS public, if you use an interface for internal consistency and good OOP practices (so really it is protected) you are stuck with making it public.

It doesn't matter if no one else will have a need to implement your interface, it is still going to out for the world to see as publc.

D-Train said...

My apologies ... I jumped the gun (not to mention that I wrote "IList and List" when I meant "IList and ArrayList" ... tsk-tsk!). I guess I never noticed this particular verbiage and I mistook it for something more remedial such as "you can't instantiate this". I should have given you more credit than that.

I do appreciate your contributions to the folks aiming to get the MCTS cert! :)

Support This Site

LinkShare  Referral  Prg