Archive for the ‘Software Architecture’ Category


You are currently browsing the archives for the Software Architecture category.

Archives

  • Categories

  • Great Design Pattern Web Site

    Tuesday, July 13th, 2010

    I just stumbled on this great web site on my travels on the Internet today its got some great information on
    design patterns, anti-patterns, refactorings and UML.

    Go ahead and take a look you can find it here.

    One Tangible Benefit of S.O.L.I.D Development

    Saturday, May 16th, 2009

    So S.O.L.I.D development seems to be the new buzz word at the moment. Now even though we all know that code that is loosely-coupled and highly cohesive leads to greater maintainability and  testability, sometimes it is difficult to tangibly measure the benefits that well structured code can actually bring to the business.

    For this post I’m going to mainly concentrate to on the first two rules of S.O.L.I.D development namely the Single Responsibility Principle and the Open Closed Principle

    A code base that follows the S.O.L.I.D principles will typically have the following characteristics:

    • A larger number of classes relative to the lines of code
    • Smaller classes
    • Smaller methods

    Now when I contrast this with the very typical, legacy code base that I am currently working with things are very different.

    • Far fewer classes relative to the total number of lines of code
    • Large (God) classes
    • Large methods

    Where I’m working currently we have a large team working on a number of concurrent projects all working in the same code base. Because of the way our code is structured we typically have a lot of problems merging our code because there are many classes that have to much responsibility, do too much and know about too many other classes. This means that the same classes time after time are modified for different projects. This in turn causes us far more merge conflicts when trying to reintegrate our code. Now problems merging code means longer project timelines and increased costs to the customer.

    When S.O.L.I.D principles are adhered to the way we write code is far different. To add functionality to our system we normally try to achieve this by adding new code and classes rather than modifying existing code (Open Closed Principle – where our system is open for extension but closed for modification). Typically because our classes do less and are smaller the chances of two projects working on the exact same class is also reduced, thus reducing the chances of merge conflicts.

    S.O.L.I.D and good OO design principles in your code are  not just wooly concepts banded around by academic types but are good sound principles that can save your organization time and money in the long run.

    kick it on DotNetKicks.com

    Don’t Design For The Unknown

    Wednesday, April 1st, 2009

    Well this is my first blog post so bare with me whilst I get into the swing of things.

    I thought I would talk about a problem we had the other week whilst working on a project for a client, when one of the developers on my project team highlighted that there was a problem with our current design. After a brainstorming session we realized that there were two solutions to our problem. The first was very simple to implement and satisfied our immediate project requirements. The second solution was more complex and the changes more far reaching on the code base.

    After consulting with our representative from the business we were told that there would be a future requirement that only option two would facilitate. Everybody on the development team screamed YAGNI but we were assured that it was 99.99% certain that this requirement would be implemented in the future as it was crucial. So back to the drawing board we went trying to flesh out option two. And there lies the problem. Even though we know that there will be a future requirement we don’t have the details for our current project. Trying to design a complicated solution with incomplete knowledge is always going to lead to an imperfect solution and probably lead to further refactoring in the long run.

    In the end we went with option one. Let the next project spec the requirement properly and design the solution correcty.