• Advertisement
  • entries
    146
  • comments
    436
  • views
    198082

Object Oriented Design

Sign in to follow this  

300 views

Previously I discussed why your design was rotting. The primary participant in this rot is a lack of dependency management. In other words, modules become much more dependent upon each other due to the various code changes. This introduces rigidity into the system, preventing changes. It also makes the system much more fragile, as any change typically results in a cascade of erroneous behavior. Object Oriented Design has many principles and patterns for helping to manage and eliminate dependencies in software design and development.

The Open Closed Principle


'A class should be open for extension, but closed for modification.' - Bertrand Meyer

The idea is simple, instead of changing a class to add a new feature, you simply extend the class (via inheritance or parameterization). You can then change the behavior in the new subclass to introduce the behavior you desire without altering existing, working code.

Take the following code, for example:
struct Protocol {
enum ProtocolType { IP, IPX, UDP } type;
};

struct IpProtocol {
Protocol::ProtocolType type;
//IP Protocol stuff
};

struct IpxProtocol {
Protocol::ProtocolType type;
//IPX Protocol stuff
};

struct UdpProtocol {
Protocol::ProtocolType type;
//UDP Protocol stuff
};

void Connect(Protocol& p, std::string connectionString) {
switch(p.type) {
case Protocol::IP:
IpConnect((IpProtocol&)p, connectionString);
break;
case Protocol::IPX:
IpxConnect((IpxProtocol&)p, connectionString);
break;
case Protocol::UDP:
UdpConnect((UdpProtocol&)p, connectionString);
break;
}
}


Now, looking over this code should, hopefully, give you a very bad taste in your mouth. Of course, this wouldn't be the only switch/if-else if-else combination in the application. Most likely it would be littered with many such examples as this one. Every time a new protocol wishes to be supported, these conditional statements would have to be updated. This code clearly violates OCP, as any new feature must alter many different pieces of code to add support for it.

OCP can be achieved through abstraction. Applying the appropriate abstractions to your code will enable it to easily be extended to add new functionality (or alter existing functionality) without requiring exiting code to change. Below you can see a simple diagram demonstrating the use of abstraction to make the code conform to the Open Closed Principle.

Now we can add new protocols by simply implementing the Protocol interface, or sub-classing one of the existing protocols. The Connect function, and any other functions dependent upon the Protocol interface, will not need to change to accommodate the new protocols as the interface abstracts the concrete implementation from the design.

Implementing this in code we end up with:

class Protocol {
public:
virtual void Connect(std::string const& connectionString) = 0;
virtual void Disconnect() = 0;
virtual void Send(std::vector<char> const& data) = 0;
virtual void Receive(std::vector<char>& data) = 0;
virtual ~Protocol() = 0 {}
};

class IpProtocol : public Protocol {
public:
virtual void Connect(std::string const&);
virtual void Disconnect();
virtual void Send(std::vector<char> const&);
virtual void Receive(std::vector<char>&);
~IpProtocol();
};

class IpxProtocol : public Protocol {
public:
virtual void Connect(std::string const&);
virtual void Disconnect();
virtual void Send(std::vector<char> const&);
virtual void Receive(std::vector<char>&);
~IpxProtocol();
};

class UdpProtocol : public Protocol {
public:
virtual void Connect(std::string const&);
virtual void Disconnect();
virtual void Send(std::vector<char> const&);
virtual void Receive(std::vector<char>&);
~UdpProtocol();
};

void Connect(Protocol& p, std::string const& connectionString) {
p.Connect(connectionString);
}



Looking over this, you are probably thinking to yourself: 'Damn, this is more code that the other way though.' However, perhaps you should implement the other code so that it provides the Disconnect, Send, and Receive functions first. At which point you will see that not only is it more code than we have currently, but it also requires a great deal more changes just to implement a single extra protocol (take SPX for instance).
Sign in to follow this  


6 Comments


Recommended Comments

Indeed. I like your journal [grin].

By the way, in the situations where a singleton pattern is appropriate (i'm thinking about using one for my global logger class and global settings class), does a singleton provide any advantage over a class with static public member functions? Member data is still encapsulated within and only accessable from the class, but some of the overhead and complexity of the singleton in removed.

What do you think?

Share this comment


Link to comment
The singleton is actually what removes the complexity and overhead compared to throwing around statics. Mistakes/bugs with singletons are usually caught compile-time rather than statics which are normally run-time errors.

Although like Washu has said you need to analyze whether the problem space fits the pattern, as the singleton is based on:

Global access
A single instance

If both of those aren't applicable than don't use a singleton.

Share this comment


Link to comment
Quite a clean and attractive design. I'm looking forward to what contraption of code you'll hand out next! :)

Share this comment


Link to comment
"The singleton is actually what removes the complexity and overhead compared to throwing around statics. Mistakes/bugs with singletons are usually caught compile-time rather than statics which are normally run-time errors."

I'm from Missouri(TM).

Of course you should not throw static *data* around, but static *functions* should be just fine - and anyway, they don't get "thrown around"; you just write Namespace::doStaticThing(), and it somehow interacts with staticData which is not directly available to the rest of the code (you don't need the 'private' keyword provided by a class to do this; you can hide things by careful use of the C++ linker, too.)

If anything, I would say the singleton approach is more prone to runtime problems (consider: someone caches a reference to the instance, then someone else destroys and recreates it), and yes it will catch things at compile-time, but it's also creating extra opportunities to mess up at compile-time ("oh, damn, I need to get the instance here, too...")

Share this comment


Link to comment
cool read, may be this kind of thing could be made in to a gdnet article to educate the masses.

I'm current reading "Agile Software Development" by Robert C Martin, it covers this stuff and more. Don't agree with everything it says, but the whole open closed principle is covered in depth.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement