I am working on a C# net micro framework project, in particular an I2C bus management/class.
I have several different I2C devices each defined in separate classes which contain all of the devices' unique methods. In my case, I can only have ONE I2CDevice
object "active" to communicate with and to switch to another I2C device to communicate with it requires a call like I2CBus.Config = DeviceConfig1
.
For example (pseudo-code):
Class Device1
-DeviceConfig1
-Method 1
-Method 2
-Method 3
Class Device2
-DeviceConfig2
-Method 1
-Method 2
-Method 3
Main Program
{
I2cBus = new I2CDevice(configuration)
Device1.Method1
Device2.Method3
}
So, somewhere between Device1.Method1;
and Device2.Method3;
When switching between devices, I need to change the I2CDevice.Config property. I call it an "OnClassEnter event" that would check that the device settings are correct before it proceeds. I'm looking for an elegant way such that whenever I call a Method for a Device, that the I2CBus.Config is automatically checked and changed. Is there a way that I don't need to re-type this config code in each method? Have a separate internal method that's called each time I access any of those methods? Maybe something inherited from a base class or Interface, but where I don't have to remember call it from each method in the Device class.
Best Answer
Instead of attempting to capture when control passes into your class and update the config then, explicitly update the configuration just before the I2CDevice is used.
Write a wrapper for
I2CDevice
which takes your DeviceConfig and I2CDevice as parameters to its constructor.The wrapper can provide its own versions of the
I2CDevice
methods (looks like there are only 3), it would then ensure I2C configuration before executing the correspondingI2CDevice
method.You would then use this wrapper inside your Device1, Device2 classes in lieu of using I2CDevice directly.
EDIT: if the I2CDevice is passed into the wrapper, the wrapper should not attempt to manage its lifecycle. I2CDevice provides a Dispose() method, in my experience (which does not include the micro framework) this indicates you risk a resource leak if it is not called. If this holds for the micro framework, you would want to provide one for the wrapper as well that calls the I2CDevice one.
Wrapper as Abstract Base:
If you use the wrapper as a base for each of your Device1, Device2 classes, the visibility of the Execute, I2CGetReadTransaction, I2CGetWriteTransaction methods and perhaps the _config field should be made protected.
Wrapper as member field: If the wrapper is a member of your Device1, Device2 classes, you would still pass your i2cBus as a parameter to those constructors, create A per Device wrapper using that devices' configuration and i2cBus and then use it going forward as you previously would have used i2cBuss.