Simon is at it again! This time he is trying to get the ball rolling with some official training with 10Gen, sponsors of MongoDB.

If you would like to know more, you can read here.

Otherwise, to go directly to the survey to register your interest, you can click here.

Learning something new isn’t easy. It can be quite frustrating at times, especially when it involves a mind shift from your normal way of tackling a problem. It’s even harder when you need to sort through the garbage and opinions of haters and fanboys, and it seems NoSQL has really struck a nerve with both sides of the camp.

Forget scalability.

There, I said it. 99% of the arguments for both sides of the camp are now nullified. So, what does MongoDB have to offer if we no longer care about it’s #1 advantage? The answer, surprisingly, is a lot.

Lets take a step back.

When I build complex systems, I use Domain Driven Design. At the heart of DDD lies the concept of aggregates. Combinations of reference and value types make up an aggregate. At the top of the aggregate lies the aggregate root. These rich domain models are the core of the system.

What does this have to do with MongoDB?

When building a domain-driven system with an RDBMS, you encounter an impedance mismatch. Domain models are made up of related objects, which can lead to deep object graphs. RDBMS is all about tables and views. A single aggregate can span many tables resulting in the need for joins and complex, resource consuming queries. MongoDB, on the other hand, deals with schema less documents, allowing you to persist entire object graphs as one JSON binary serialized document. This means no joins are required yet you can still query each individual object as if it was in its own table.

More thoughts

Truthfully, I didn’t know what to expect when I first used MongoDB. There was so much crap surrounding the hype on the internet that it was almost impossible to find any substantial truth on the subject. I didn’t know what to believe. The only solution was to try it out for myself.

Mongo: Head first

The initial setup wasn’t as smooth as it could have been. While it was still a lot quicker than configuring an MSSQL instance, it wasn’t without hiccups. The only real problem I ran into was after installing mongo as a service, it would not run. It turns out that for whatever reason, the directory containing mongo binaries needed to be installed on my C:\.

Once installed, learning the querying syntax was very easy. You can tell it was designed with programmers in mind. I had a play around with mongo before attempting to integrate it into my system, creating and querying documents etc.

When it came time to try it out in code, I decided to on the NoRM MongoDB driver (I’ll cover this later). Within minutes I had the NHibernate factories swapped out for the MongoDB factories. It was an incredibly quick and easy process.

All in all, I was pleasantly surprised with not only how easy MongoDB is to install and learn, but how much functionality the C# drivers provided, with nearly all linq operations supported. Just as surprising was the beneficial side-effect of thinking in documents actually helps to refine your aggregate/domain model.

If you haven’t already noticed, all my previous blog posts are missing! A little over a week ago, the VPS that was running this blog was paused for scheduled maintenance while the VMWare hypervisor underwent updates. Unfortunately, the image never restarted. The image file was corrupted beyond repair, and there was no backup. In short, everything was lost.

So, now begins the task of rebuilding the content from my saved feeds. I don’t intend on restoring everything, so I do apologize in advanced if something from google is missing.

I do however, intend on moving onto bigger and better things. I have been busy working a project in my own time and I wish to document the architecture, so stay tuned for some REST, NoSQL, ASP.NET MVC and NServiceBus and the challenges of making them all work together.

Part 1 here.

The Liskov Substitution Principle states:

“If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.”

When using inheritance, a subclass should be able to be used wherever a super class is used, without altering program behaviour. If we refer back to the OCP, we know that classes should be open for extension but closed for modification. As I stated previously, when extending class behaviour it is important to keep in mind the LSP. Overriding a method is dangerous as you could unintentionally alter program behaviour. In order to prevent this, there are a few rules we can follow: 

Wikipedia states:

Preconditions cannot be strengthened in a subtype.

Postconditions cannot be weakened in a subtype.

Invariants of the supertype must be preserved in a subtype.

History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Since subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this. The was the novel element introduced by Liskov and Wing. A violation of this constraint can be exemplified by defining a MutablePoint as a subtype of an ImmutablePoint. This is a violation of the history constraint, because in the history of the Immutable point, the state is always the same after creation, so it cannot include the history of a MutablePoint in general. Fields added to the subtype may however be safely modified because they are not observable through the supertype methods. One may derive a CircleWithFixedCenterButMutableRadius from ImmutablePoint without violating LSP.

Perhaps one of the better examples I have come across regarding violating the LSP is this one on doodle project, using linked lists.

The Interface Segregation Principle states:

“Make fine grained interfaces that are client specific.” OR “Clients should not be forced to depend upon interfaces that they do not use”

It’s almost common place to see an object of Customer inherit ICustomer, but what benefit does it really give you? Abstraction you say? Maybe you will want to proxy the object later on to write your own lazy loading when you optimize the system? You know it’s good practise, so you do it.

Well, I don’t like that design. In fact, I cringe at the thought. I consider it an anti-pattern, the fat interface anti-pattern (it probably has another name, I don’t know). By doing this, we limit ourselves to getting the full benefit of code reuse, amongst other things. Interfaces should describe what functionality a class offers. You don’t see IDisposable implemented by a concrete class called Disposable, no, you see it adding functionality to an existing class, telling the world that the class has custom logic that needs to run when you dispose of that object.

You break down fat interfaces into more logically grouped contracts of functionality and then compose them to create a single object. Customer : IContainsAddress, ICanBuyStuff, IHaveOtherFunctionality etc etc. then you can pass customer to any method that accepts the above mentioned interfaces.

Finally,

The Dependency Inversion Principle states:

Depend on abstractions, not on concretions.

Chances are, you have heard the term inversion of control being thrown around. Well, IoC is a way to “invert” the flow of control within a system. Dependency injection is a specific form of IoC where you inject dependant modules into an object. That object depends on an abstraction (commonly an interface) to describe the intent of the object, however it does not know any more implementation details beyond this.

Dependency inversion is an architectural decision to decouple layers between a system, allowing you to build a more robust, maintainable, extendable and adaptable system with less effort and impact than you would encounter in a traditional, top down procedural style of architecture.

No matter where you turn in the blogosphere, chances are you will eventually come across a post on the SOLID  principles of OOD. As such, I quite often refer to the principles in discussions with other developers as if it were common knowledge. Quite often, however, I am asked to elaborate on these principles.

What is SOLID?

SOLID is an acronym for a set of principles of object oriented class design. It stands for:

• Single Responsibility Principle (SRP)
• Open Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

What is so good about them?

These principles combined, help to manage code dependencies by guiding the developer to write cleaner, well structured code to avoid OO anti-patterns and spaghetti coding. Adhering to these principles results in maintainable, flexible, robust and reusable code.

Breaking down the principles:

The Single Responsibility Principle states:

“A class should have one, and only one, reason to change” OR “There should never be more than one reason for a class to change”

A class should have one responsibility, and one responsibility only. One way of identifying whether or not you have violated this principle is by describing to yourself out aloud what the class does. If you hear the word “and” in there, chances are you have violated this principle. For example, if you designed a class that calculates a list of mathematical equations and emails the results to a recipient, you would have violated this principle. The class has two reasons to change (or responsibilities).

If the customer decides he no longer wants to receive the information via email, instead sending an SMS over the mobile network, then there is a reason to change. If the customer decides they want to change the way the equations are calculated, there is another reason to change. Perhaps the most extreme anti-pattern to this principle is the God object anti-pattern whereby a single class does almost everything imaginable in the system.

The SRP can be related with cohesion. A class that conforms to the SRP will be highly cohesive, as each method in the class will be closely related to its sole purpose. A class that does too many things is likely to have low cohesion.

The Open Closed Principle states:

“You should be able to extend a classes behaviour, without modifying it” OR “Software entities should be open for extension, but closed for modification”

At a glance, the principle may seem contradictory at first. How do you “extend” behaviour without modifying code? Quite easily, actually. Inheritance after all, is one of the fundamental designs of object oriented languages. As Martin puts is, abstraction is key. Inherit from an abstract class, mark methods as virtual, allow your class to be extended by it’s subclasses.

However, while it may seem the principle heavily promotes inheritance, it is always good to remember that it is best to “favour composition over inheritance”. It is also important to remember not to violate the Liskov Substitution Principle – as we will see later on.

In the next post we will look at the remaining principles of SOLID OOD.