To wrap or not to wrap

I assume this is a rather subjective question, so I will put a concrete example.

Considering the design of a set of wrapper classes for wrapping access to WMI information using a namespace System.Management, I had a problem when I started wondering how I can satisfy situations where a one-time value is required, say, the BIOS serial number from Win32_BIOS, as well as in situations where many different properties or more complex searches may be required, such as searching files in CIM_DataFile.

This made me think about whether to add the functionality presented in the System.Management namespace at all, or in the end I will add unnecessarily complex and long wrapper classes to reduce the amount of code in the application.

What is the general agreement with this problem, is it worth writing complex wrapper classes in the hope of saving time, or is it better to just stick to the flexibility of the built-in classes, even if it sometimes doesn't seem particularly clean or tidy.

+4
source share
1 answer

The purpose of a wrapper class is to hide complex functionality from the caller.

In other words, if the entire calling application wants to do this, to find out the serial number, then it should just call something like myobj.GetSerialNumber()that that would make all WMI calls necessary to return this value.

, WMI , WMI , .

+4

All Articles