Design Patterns & Architecture

  • Code on Different Types of Codebases

    A lot has been written about blogging and working on open source projects to improve your coding skills. They are great ideas. In addition, I like attending user groups.

    But there is more. Becoming a great software developer also means making sure you are able to think as the situation demands, as opposed to being biased in the manner that your current project is developed. It means making sure you are comfortable building very different types of projects.

  • Diagramming Tools – A (Biased) Survey

    Diagramming tools can help you to quickly understand a new project, debug code, visualize and enforce usage patterns, and quickly generate high quality documentation.  All good.  However, not all tools are created equal and there are lots of legacy tools (UML has been around for a while).  I wanted to take a look at what is out there to get a sense for how these tools are evolving.

    Below is a slice if you will through what are some next generation offerings in software development, tools that are trying to do something different, and some well established old-guard tools that everyone has heard of and compares all comers too.

    Code Canvas Example

    Debugger Canvas  Debugger Canvas by Microsoft (see video) is based on Code Canvas which was developed at Microsoft Research in  collaboration with the Code Bubbles folks from Brown.  Debugger Canvas is available to premium Microsoft Visual Studio license holders.  I love how you can view a GUI widget, its documentation, and implementation side by side in one clean view.  The development metaphor is very different from a traditional IDE.

     

  • Code Visibility: one factor of code quality that you shouldn’t forget

    Every developer cares about code quality. But how do you maintain code quality throughout the software development cycle? Readability, modularity, and efficiency all are important factors of writing good code but there isn’t much agreement on the best way to maintain a high level of code quality.

    One factor which is often missed in discussions is code visibility, or making sure your code has a clear structure so that others can easily understand it. (Take a look at the diagram above for some of the difficulties encountered when there is a lack of code visibility).

  • A simple intro to creating a MVC framework: Using GEF

    When creating a rich graphical editor the Model View Controller (MVC) design pattern makes life a lot easier. But it is often difficult to decide which libraries/frameworks to use. On the Eclipse platform GEF (Graphical Editing Framework) is a great solution but it can be challenging to figure out how to integrate with the parts you need. Since GEF is built on top of the Draw2d/SWT graphical libraries and is able to provide a powerful and consistent UI. However there are many considerations and pitfalls to take into account when getting started with GEF.

    Some of my first large scale Java coding involved using and modifying GEF code. Luckily the GEF team provides many helpful examples showcasing the different features GEF offers. I will attempt to provide a concise introduction to the points that I found best helped me understand GEF.

  • REST Architecture – Simplified

    Recently, while working on some collaboration functionality for our suite I got a chance to work on a REST (Representational State Transfer) based web server. There are many great resources about REST out there but most of them are quite technical and it took a me a while to get it. So, in this post I am trying to explain in some simple terms what I have understood about REST.

  • Wasting Time With Test Driven Development?

    Many teams are moving to test driven development and very often this a good thing. In a drive towards increased code stability and maintainability, good test cases can be very helpful. But this is not always the case; while working with development teams, most teams seem to have one or more critical problems. It seems that it is easy to do Test Driven Development (TDD) badly – below are five situations that I have seen multiple times.

  • Commands and the MVC architecture

    Most of us agree to the benefits of using commands to provide the undo-redo functionality in an MVC based application. Working on one such highly interactive application, the question which often arises is where in the code base do the commands belong: in the model, in the controller or as a separate entity. This issue has been discussed before and people seem to have quite disparate views implying a vague understanding of this problem. In my view commands should be considered separate from both the model as well as the controller. This becomes really important while organizing your code to have clear abstraction boundaries and conform with the principles of cohesion and coupling

  • Cohesion and Coupling in Large Projects

    Cohesion and Coupling are commonly used metrics to gauge the design quality of a software project with regards to maintainability, reuse and understandability. These issues are commonly faced by developers working with large codebases. The mantra for these issues is to have a highly cohesive and loosely coupled code__base.

    Simply stating, Cohesion means placing related code in one particular unit and Coupling is the degree of dependency between two or more units. If the code is highly coupled i.e. different units depend a lot on each other and modifying one feature can cause unwanted side effects. To avoid these the developer has to understand each of the related classes to update the behavior safely. Loosely coupled code is easier to reuse and on modification does not have undesired ripple effects in the code base. Adding to the benefits highly cohesive code promotes easy code understandability as everything is placed closely together. These aspects are not restricted to classes but apply to everything from methods in a class to packages in a project.

  • No, You are not Dumb! Programmers do spend a lot of time Understanding Code…

    While working on a codebase, developers spend a lot of time understanding code. We might be unwilling to admit it for fear of sounding dumb but the huge amount of time spent on making sense of code is staggering. In fact a conference is held every year just to tackle this problem...
  • Types of Dependency Injection

    In continuation with my effort of trying to simplify Dependency Injection, I want to elaborate on the different types of injection. Dependency Injection is decoupling an application and service so that the application does not need to know anything about the service implementation. Dependency injection can be broadly classified in three categories: Constructor, Setter and Interface.
    Object dependencies when passed as parameters to a constructor is termed as Constructor Injection.
    <br /> public class Account {<br />   public User user;<br />   public Account (User user) {<br />    this.user = user;<br />   }<br /> }<br /> </p>

    Pico Container is a framework which prefers constructor injection. Constructor injection ensures that the application object is created with all its service dependencies satisfied.

  • Simplifying Dependency Injection

    A lot has been written about Dependency Injection (DI) however, it still remains a complicated topic. The main articles on this topic are quite thorough and provide really good information but in the process, the basic principle behind DI becomes hard to comprehend. DI is in fact fairly simple – its main goal is removal of a class dependency on some code. This class dependency is then ‘injected’ into the code where it is needed. Using dependency injection helps in code maintenance, re-usability, testability, and improves code readability.

    An Explanatory Example

    In one of my projects, we needed to use DI to inject different implementations into a core service. Our project needed to be deployed to multiple types of servers while we wanted to share large portions of the core code and at the same time have different functionality for users.

  • Dependency Injection, Frameworks, and You

    3D Character and Question Mark

    I have previously tried explaining Dependency Injection and how it can be beneficial to any project. This leads us to an important question about whether to use a framework or to do injection manually. Using a framework all the time may not provide you with additional control, rather at times it may further complicate the code. On the other hand implementing dependency injection manually can sometimes become more time consuming and painful. So how do we actually choose?