Category Archives: Architecture

A look into SOLID principles

February 2, 2014 6:02 pm /

In an effort to look into how I can improve my code and the code bases I work on at work and the projects I have at home, I have decided to look into the SOLID principles and what they mean.

The idea behind the Solid principles are are to get you the developer to think about the classes / code you are writing before you begin.  The way I see these principles are that they are a great guide to help plan out what we are trying to achieve.  This way we don’t just dive straight into the problem we are trying to solve but we take the time to think it through.  All of the great developers I know and have had the privilege to work with have helped me to see what these principles are and how to put them into practice.  To often we look at this with a purely academic mindset rather than with practical outlook, so lets see what each of these mean and how to do it in a real life situation:

 What does it stand for

  • Single Responsibility Principle
  • Open Closed Principle
  • Liskov Responsibility Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

 Single Responsibility Principle

This principle here is stated that each class should have a single responsibility and and single reason to change.  The second part of that explanation really threw me until I saw an example.  In the example the class in question was asked what would make this class change.  If the answer was multiple things then the class needed to be split up into multiple classes.  So for example if the class handles the

 

Open Closed Principle

For some reason this always reminded me of Robocop!  Why, because the shortened version of this is OCP.  Anyway this principle can be stated that a class is open for extension but closed for modification.  This can easily be explained by saying that instead of changing the original class the class can be extended to alter its behaviour.  An obvious implementation of this is inheritance.  With the use of a base class the functionality can be extended.  The benefits of this are of course unit testing because the original has not been altered in any way.

 

Liskov Responsibility Principle

The Liskov responsibility principle revolves around the use of of sub types or classes.  In Object oriented programming if you have a base class of type Animal and a class that extends Animal called Dog.  When the type Animal is used in the code, it should be able to be interchangeable with the type Dog with no ill effects.

 

Interface Segregation Principle

The interface segregation principle states that the clients should not be forced to depend on the items they do not require.  The way that this work is that if a class is dependant on another class, the interfaces between them should only expose what the client needs.

 

Dependency Inversion Principle

The dependency inversion principle has another name, Inversion of control.  The way this principle works is that that the the way that a solution is put together, the pieces involved are depending on abstractions rather than concrete implementations.  Now you may ask, what does this really mean?  Well if you had Class A which used Class B.  You could just instantiate B in Class A, but what this principle is trying to help you do is rather to rely on an interface that will be instantiated at runtime.  This means that rather than instantiating the class at compile time you wait until runtime to sort it out.  Which ties in to the interface segregation principle, so you should not be forced to see more than they require.  This also helps with keeping your code clean and your dependencies light, so if something has to change the impact is low.

Posted in: Architecture, Code Smells / Tagged: ,

What Does REST mean and how to implement it

November 2, 2013 6:05 pm /

The term REST has been coming up a fair amount over the last while so I thought I would look deeper into what this means and how I would use it. I am primarily develop web related applications so I was interested in how this would affect the way that I design / architect the solutions I am involved in.

What is it

Rest (Representational state transfer, thanks wikipedia) is an architectural concept in which defines rules for the way that applications communicate.  For the most part when I was researching this, most of the definitions tended to focus mainly on REST vs. SOAP, but it could be applied to any interaction between applications.  To be defined as Restful the application must be designed according to the following principles:

  1. All components being accessed in the system are all accessed in a unique way.  To break this down we need to understand that the way that we access the component we would need to know what we are accessing or the name of the component as well as a identifier for that component.  This means that if I was to get this article from the blog then I would use a URL that clear defines what it is I am looking for: www.blog.com/article/1.
  2. The API should respond to all calls with an appropriate response code and / or a JSON object:
    • 200 OK
    • 201 Created
    • 204 No Content
    • 400 Bad Request
    • 401 Unautherized
    • 500 Internal Error
  3. Use commonly know actions to allow the client to communicate with the system.  In this case it should be common HTTP actions: GET, POST, PUT etc

Example

public class RestController : ApiController
{
    // GET api/values
    public IEnumerable<JsonUser> Get()
    {
        return new IList<JsonUser>();
    }

    // GET api/values/5
    public JsonUser Get(int id)
    {
        return new JsonUser();
    }

    // POST api/values
    public void Post(JsonUser user)
    {
        //Add saving logic here
    }

    // PUT api/put
    public void Put(JsonUser user)
    {
        //Add saving logic here
    }

    // DELETE api/delete/5
    public void Delete(int id)
    {
        //Add Deleting logic here
    }
}
Posted in: Architecture / Tagged: ,