My time as a developer (~8 yrs) has been spent creating tooling/automation of on

Question

My time as a developer (~8 yrs) has been spent creating tooling/automation of one sort or another. The tools I develop usually interface with one or more API's. These API's could be win32, WMI, VMWare, a help-desk application, LDAP, you get the picture. The apps I develop could be just to pull back data and store/report. It could be to provision groups of VM's to create live like mock environments, update a trouble ticket etc.

I've been developing in .Net and I'm currently reading into design patterns and trying to think about how I can improve my skills to make better use of and increase my understanding of OOP. For example, I've never used an interface of my own making in anger (which is probably not a good thing), because I honestly cannot identify where using one would benefit later on when modifying my code. My classes are usually very specific and I don't create similar classes with similar properties/methods which could use a common interface (like perhaps a car dealership or shop application might).

I generally use an n-tier approach to my apps, having a presentation layer, a business logic/manager layer which interfaces with layer(s) that make calls to the API's I'm working with. My business entities are always just method-less container objects, which I populate with data and pass back and forth between my API interfacing layer using static methods to proxy/validate between the front and the back end.

My code by nature of my work, has few common components, at least from what I can see. So I'm struggling to see how I can better make use of OOP design and perhaps reusable patterns.

Am I right to be concerned that I could be being smarter about how I work, or is what I'm doing now right for my line of work? Or, am I missing something fundamental in OOP?

EDIT: Here is some basic code to show how my mgr and api facing layers work. I use static classes as they do not persist any data, only facilitate moving it between layers.

public static class MgrClass
{
    public static bool PowerOnVM(string VMName)
    {
        // Perform logic to validate or apply biz logic
        // call APIClass to do the work
        return APIClass.PowerOnVM(VMName);
    }
}

public static class APIClass
{
    public static bool PowerOnVM(string VMName)
    {
        // Calls to 3rd party API to power on a virtual machine
        // returns true or false if was successful for example
    }
}

Explanation / Answer

Sounds like you might be missing a lot. Development patterns have been around for a long time and they really help with OOP. I would suggest reading about these patterns.

For a start have a look at SOLID - http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) There are 5 basic development patterns.

With regards to interfaces, they are really usefull. Interface defines the methods available and the concrete class provides the implementation. If you use interfaces you can easily swap classes to provide different functionality (without having to change the rest of the application). An example of that would be data access layer. Imagine if you develope your application which uses LINQ to SQL. Some time later the requirement is to change the data provider to something else. Now, if that was running of an interface with properly implemented Command Pattern http://en.wikipedia.org/wiki/Command_pattern , this would be very easy. You would only have to create new data access layer, implement the interface and that's it.

It's worth reading about the design patterns and all features given by OOP.

Hope that helps.

UPDATE

Based on your example, your APIClass already follows single responsibility pattern.

The way you could implement interface would be :

public interface IVMManager
{
bool PowerOnVM(string VMName);
bool PowerOffVM(string VMName);
}

public class MgrClass
{
private IVMManager _vmManager;

public MgrClass(IVMManager vmManager)
{
_vmManager = vmManager;
}

public bool PowerOnVM(string VMName)
{
// Perform logic to validate or apply biz logic
// call APIClass to do the work
return _vmManager.PowerOnVM(VMName);
}
}

public class APIClass : IVMManager
{
public bool PowerOnVM(string VMName)
{
//IMPLEMENTATION
}
}
REMEMBER : static methods cannot be exposed via interface !

This example also follows the command pattern. VM Manager is easily swapable with different implementation. You can also unit test this class.

Hope that gives you an idea how design patterns can be used and how powerfull OOP is.

Related Questions

Navigate

• Browse (All)
• Browse M
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.