Good Practices

This section is a collection of inspirational advice which we have gathering following our Agile Sprint retrospective with our design and delivery teams. We hope give back what he have learn the hard way so that your software development team leads and managers can overcome challenges, improve their performance and excel.

We cover a wide range of industry toolkits, e-learning and development aides for a wide range of areas within software engineering. These can be utilised as standalone resources or seamlessly integrated into your organisation’s application design, development and business processes.

Here are a few fundamental concepts of software development largely in play commercially today.

SOLID principles of Object Oriented Design


The SOLID principles of Object Oriented Design include these five principles:


The Single Responsibility Principle

A class should have one, and only one, reason to change.


The Open Closed Principle

You should be able to extend a classes behavior, without modifying it.


The Liskov Substitution Principle

Derived classes must be substitutable for their base classes.


The Interface Segregation Principle

Make fine grained interfaces that are client specific.


The Dependency Inversion Principle

Depend on abstractions, not on concretions.

The Don’t Repeat Yourself (DRY) principle states that duplication in logic should be eliminated via abstraction; duplication in process should be eliminated via automation.

You can probably see that the SOLID principles overlap a lot. For example, the SRP provides a good way of splitting interfaces to follow the ISP. The ISP helps implementers conform to the LSP by making implementations small and cohesive. You may also notice that some of the principles contradict, or at least pull in opposing directions, such as the OCP requiring inheritance while the LSP tends to discourage it. This interplay between the principles can provide a really useful guide while developing your design. I believe there are no perfect designs, just trade offs, and the SOLID principles can help you evaluate these and achieve a good balance. The fact that there is some measure of conflict between them also makes it obvious that none of the principles should be applied rigidly or dogmatically. Do you really need a huge interface explosion due while adhering to the OCP and DIP? Maybe, maybe not. But considering your design options in light of the SOLID principles can help you decide.

A lot of SOLID principles seem to fall out fairly naturally if you practice TDD (or BDD). For example, writing an effective unit test for a class is much easier if you follow the DIP and isolate your class from its dependencies. If you are writing the tests first to drive your design, then your class will naturally tend to use the DIP. If you are retro-fitting tests, then you’ll likely encounter more difficulties testing, and may end up with interaction-style tests, re-writing the class to use the DIP, or worse, throwing it in the too hard-to-test basket.