Posts Tagged SDLC

Program to an interface , not an implementation

I have been lately discussing SOLID in my previous posts – some of the basic principles of OOD . Recently while doing my project work , we had to decide between Entity Framework  or NHibernate which are popular ORM layers in .Net framework .  The decision was not easy , we got stuck at Second Level caching support …and could not reach any decision right away. I started thinking that may be for now we have to write our layer in such a way that we choose one ORM , and then we can switch to a different one worst case if need be. Ideally a situation like this should not arise , but if it does happen , you need to be able to do it.  Once again I felt how a very fundamental OOD principle could come in handy –

Program to an interface , not an implementation.

These words above can be very ambiguous and abstract when you just read them .

However when seen from a context , you understand how powerful this is , and how it can increase flexibility and ability to switch . Seen from my own situation where we needed the flexibility to switch data access mechanism if need be, let’s understand this by constructing a scenario. For example , a common problem could be implementing a subscription mechanism for a data service that your system may provide. Users can subscribe to the data service and get notified when a change occurs. We need to persist the subscription information to the database , where you will need to use some database access mechanism.

As usual there is a presentation layer that gathers some subscription information and passes it along to the data service which persists the information to the database . For simplicity’s sake , let’s say we have a SubscriptionService , which is our data service for persisting subscriptions . We can discuss this further in the context of an ASP.Net MVC application – where a View is our Presentation layer through which Subscription details are collected. A controller action method is typically invoked to pass along the information to the server.

We can assume for our article purposes that our application provides notifications on Food Recalls. So the member user to our website subscribes to recalls for a certain type of food issued by different organizations like FDA etc. The Subscription in simplicity could be :

Please note : all code is pseudo only , this is not a working solution that can be downloaded and built.

public class RecallsSubscriptionService
    Boolean Subscribe( int userId, string food_type, string organization)
           // data access code to insert subscriptions
           return false; 

Most of the times the controller action method would look something like this:

public class SubscriptionController : Controller
        public ActionResult Subscribe(int userId, string food_type, string organization)
                 SubscriptionService myservice = new SubscriptionService();
                 myservice.Subscribe(userId, food_type, organization);

                return RedirectToAction("Index");
                return View();

So , we make a decision we will use Entity Framework 6 to implement our data access to store subscription information. The above code will work fine . The code goes into production . However later we decide that due to certain project requirements we have to switch to NHibernate. This is a tough situation – our controller here , who is a client of the SubscriptionService , is heavily dependent on instantiating this specific service which accesses the database with Entity Framework 6. Although we expected the problem could arise we didn’t design our system for this flexibility. Even though we encapsulated the data access code into a Service , we did not free the client from the implementation of data access because the client program is indirectly tied to EF implementation.

We need to make some changes , so our controller is independent of the future changes that could happen to the database access mechanism. To bring transparency into how data access may happen from a client’s perspective we need to introduce interfaces. We write an interface instead for the SubscriptionService :

interface IRecallsSubscriptionService
   Boolean Subcribe(int userId, string food_type, string organization);       

We could write two implementations of the above interface or we could just use the same implementation we had earlier , and replace it with NHibernate.

public class RecallsSubscriptionServiceEF
       Boolean Subscribe(int userId, string food_type, string organization) 
                //   implement using EF ;
                return false;

public class RecallsSubscriptionServiceNH
       Boolean Subscribe(int userId, string food_type, string organization) 
              //implement using NH ;
              return false;
/*( not that the above approach is recommended , where you keep 
two implementations available for the same requirement. 
This is for understanding purposes only )*/

The above mechanism allows us to drive the Subscribe method call through the IRecallsSubscriptionService interface. In order to effectively use the method above , we will need to pass IRecallsSubscriptionService as a parameter to the controller constructor and use dependency injection in this scenario to have the right concrete class to be instantiated during run-time. I will not dive deeper into that because it is outside of the scope of this topic.

This is the whole basis of Dependency Inversion and Injection ( this is also the ‘D’ in SOLID ): here we program to an interface , not an implementation as we saw above. This gave us the flexibility to change our implementation completely without changing the client code. So the basic idea is programming to an interface decouples the client from the internal implementation freeing calling programs from knowing the internals leading to flexibility in changing implementation as the need arises.

Even in scenarios where there are published APIs , when you use objects  go up in hierarchy to program to the interface as opposed to the concrete class. So if you are using a List object and comparing individual strings-  then if this object implements IComparer , then program to IComparer –

instead of writing:

List myList = new List();
myList.Compare( myList[0] , myList[1]);

//Write as :

IComparer myList = new List();
myList.Compare( myList[0], myList[1] );

//This gives you the freedom to use a different flavor of Compare method if you need to ,

IComparer myList = new Array();
myList.Compare( myList[0], myList[1] );

The advantage of the above is ability to switch different comparison methods if they are available. And also test program can easily switch different implementations and see what works the best.

We also need to understand that “Program to an interface” should not be taken literally . Even Abstract classes can act as interfaces in this context and give us the same flexibility.

Interfaces should be used wisely and only when needed. If there is no potential for an implementation to ever change there is no need to bother with interfaces. For example , a Utility class that converts a string to a number. There is no need to write interface to this . Interfaces should also be used in projects where testability is a big concern and mocking may be required.


, , , , , ,


UX Designers and Developers: Bridging the gap

The other day I was watching a presentation on SlideShare about how the UX designers can work with Developers without getting into conflicts. All my career like many Software Engineers I have had to interact closely with UX designers …the problem mostly stems from the fact that the tools used by both the groups are different as well as the frameworks and languages to achieve the end result . There is some overlap between the two with Javascript / JQuery – however, depending on whether the Client Script impacts the UX interaction or some server related activity , the designer or the developer takes over the definition of the code. A synergy needs to be created between both of them because at the end of the day the UI that we see is the combined effort of these two groups.

The tools and frameworks themselves don’t offer much in terms of creating that collaboration and synergy – however as part of the process , the groups need to mingle and work side by side. Designers do need to understand how the developers incorporate their code into the designs- and developers need to understand to a certain extent the working of Styles and HTML .

Just recently I went through two ASP.Net MVC projects and we used the help of a UX team to put together our styles and layouts. As usual, the mock ups were created which the developers used to incorporate their code into, to achieve the end user requirement of the UI.   There were issues with how the developers had used the mock ups with their code , as expected. Most times the designer would call me and say hey I need to be able to run the web page in development like the developers do, so when I make a change I see it and go through iterations. I made a decision that she needs to get familiar with running the solution in Visual Studio 2010. This helped a lot – saved us precious time by the designer not having to ask the developers to make a fix and publish it on the dev server. The designer at the same time was happy having the independence to make the change in the final UI and seeing the page in debug mode.

One of the other bad practices I noticed with a recent client is that the UX designers would put their wire frames either in Dropbox or zip them up and email the development team. The development team had to always download them and copy one by one in their project. There was no version history , no way to tell what changed other than looking at the rendered page . This can become a development nightmare in a very UI centric project.

All mock ups and styles should be version controlled , preferably in a similar version control system as being used by Developers. This makes it easy for Developers to compare the changes as well as Share the styles if it makes sense into their project from the styles folder of the Designer team in Source control .

I am not sure in the future how much will be offered by Development tool makers in terms of both Developers and Designers being able to use the same tool to do their jobs. However I think if Designers and Developers both understand to a certain extent each other’s code , work side by side and follow good version control practices,  the UI development would be much less of a hassle. The Designers need to understand the interweaving of Server side code with Client side code and the Developers need to understand Javascript , CSS and HTML standards to a reasonable extent.

So there need not be any love lost between Designers and Developers – collaboration and communication can surely bridge the gap.

, , ,


TFS : Make the most of it

The decision to buy TFS or Team Foundation Server is not an easy one ; it’s an expensive product, although Microsoft has introduced TFS Basic as of this writing , however several larger organizations with budgets have already invested in the TFS full version. Interestingly enough , where I was before I worked for different groups who all used TFS , but barely tapped it’s potential. TFS almost immediately gets adopted as a Source Control because of  it’s  containment inside Visual Studio IDE. It easily becomes a developer’s everyday tool where developers use it for Source Control as well as Continuous Integration. The Continuous Integration support works off of the IDE again and you need not use any other tool to configure it. The only other configuration that happens is on the Server side where you are hosting the Team Foundation Build Service. So , this is still in the Developer’s paradigm or a Build Master who interacts directly with Developers.

However , this is barely any use of what TFS can offer – TFS is an End To End SDLC tool which can be used for the entire Life Cycle Management of the Project by all team members without having to use anything else. Team members include non developers like Business Analysts, Project Managers , Testers , End Users and other Stake Holders. However the problem with all these non developers using TFS comes with TFS client being Team Explorer which installs a shell of Visual Studio and uses the Visual Studio interface for TFS connectivity . This can turn off a lot of non developers in the team from using it because most of these people are not used to having Visual Studio as an application on their machines.Even the Developers ended up not making full use of it because Project Managers or BAs don’t use it where Requirements and Work Items can be created, against which development can be done and tracked.

If your organization has already invested in TFS , I think you must make a dedicated effort in getting everyone to make use of it so the entire SDLC can be managed efficiently with just one tool.  This blog is not meant to be an advertisement for TFS : the idea is if you have chosen to invest in TFS , get most on your investment by getting the Team to use it as SDLC tool so you get the right value for your money. TFS integrates with Sharepoint and MS Project Manager – two very popular enterprise Project Management and Collaboration tools. The adjustment needs to happen mainly in installing the Team Explorer client which is Visual Studio GUI interface . I have used VS 2008 Team system and started using the 2010. Team Explorer for 2008 is free and a seperate install. Once that’s done you can connect to TFS server and your Team’s project and  manage everything from there itself.

We used TFS for our entire cycle as well as Post Production support for one of our projects. One major issue we found was we had our customers create issues in Sharepoint site of the Team Project . As of this writing the 2008 version lacked a good integration where the Work Items or Issues created by Sharepoint users could not be easily imported into the Visual Studio client interface. We had to Excel export the Sharepoint items and then import them back into Team explorer through Excel, which is a kind of round about way to achieve something that could have been offered as simple one click function from the tool itself. I am not sure if they fixed this in the newer 2010 version , if so then completes the product without any holes for SDLC management.

PS: we used TFS for all of our .Net projects . I know that TFS can be used with other stacks as well , like Java for example – however not sure if the Continuous Integartion would work correctly for Java because TFS Build engine uses MSBuild and the .Proj files to make builds. Anyways if you are a MS shop with .Net projects then TFS is definitely a great project management and collaboration tool.

, ,