Mar 152013
 
Share...Tweet about this on Twitter4Share on Facebook1Share on Google+11Share on StumbleUpon0Share on LinkedIn3Flattr the authorPin on Pinterest0Share on Reddit0Share on TumblrDigg this

Software Development is so many things; to have a good start creativity, passion and methodology have to be a perfect match.

software

While the creativity and the passion are subjective and personal, the methodology is something that can be learnt, developed, enhanced and shared. Like mathematics, it can be seen as an universal language.

Principles

When developing software there are some best-practices and principles that should be followed so that every software developer should be able to read and understand the application quite quickly.
In general, the principles, when applied, should be able to (and not only)

  1. minimize maintenance requirements
  2. minimizes costs
  3. promote usability and extensibility
  4. promote testability and correctness of the application

Some of the key principles are as follows:

Separation of concerns

Expressed in a simple sentence: “Divide your application into distinct sections with as little overlap in functionality as possible.”. Easy to say, difficult to achieve.
Separation of Concerns is one of the fundamental tenants in object oriented programming and, when applied correctly, promotes loose coupling and high cohesion, which are two very important principles to be aware of.
Layered Architecture
Separating the application into several layers, is already a good start, but then one should also follow the same principle into each of the layers. Presentation layer shouldn’t do what Data Access Layer does and vice-versa. For instance Domain Driven Design helps and promotes the separation of concerns.

Single Responsibility principle

The term was introduced by Robert C. Martin. Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change.

In the (very simple) example below it is pretty much clear that the GetCustomerById() shouldn’t be par of the Person class.

public class Person
{
    public Person GetPersonById(){/*...*/}
    public Customer GetCustomerById(){/*...*/}
}

This should be a much better design:

public class Person
{
    public Person GetPersonById(){/*...*/}
}

public class Customer
{
    public Customer GetCustomerById(){/*...*/}
}

Principle of Least Knowledge

(also known as the Law of Demeter or LoD).

A component or object should not know about internal details of other components or objects.

Example:


//this should be avoided:
    customer.wallet.totalMoney;
    customer.apartment.bedroom.mattress.totalMoney;
    customer.apartment.kitchen.kitchenCabinet.totalMoney;

//instead this could be an idea of usage.
    customer.GetPayment(/*...*/)

Check this amazing paper that explains in detail what is the Law of Demeter all about.

Don’t repeat yourself (DRY)

You should only need to specify intent in one place. When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.

Minimize upfront design

This principle is sometimes known as YAGNI (“You ain’t gonna need it”) and it’s about designing only what is strictly necessary in order to achieve the goal.
A good example is the incremental development, where the system get’s enriched “on going” rather than planned (heavily) upfront, as during the application lifecycle the requirements often change too often.
In Agile development, you can avoid big design upfront (BDUF). If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely.

Final Thoughts

As usually, I just scratched the surface of the issue and there are many more items to add, but that could be part of another post.
I invite you to read about the above concepts as it would improve your application.

Share...Tweet about this on Twitter4Share on Facebook1Share on Google+11Share on StumbleUpon0Share on LinkedIn3Flattr the authorPin on Pinterest0Share on Reddit0Share on TumblrDigg this

My name is Zoran Maksimovic a Software Developer and Solution Architect. I'm interested in Software Development, Object-Oriented Design and Software Architecture all this especially bound to the Microsoft.NET platform. Feel free to contact me or know more in the about section

  One Response to “Key design principles in Software Development”

  1. Thanks for the post. please keep posting.

Leave a Reply

powroznik.rpo@mailxu.com