• The importance of Software Development Principles & Patterns

    by
    frosty
    Published on 10-13-2011 06:13 AM
    0 Comments Comments
    It’s becoming cliché in a lot of the literature that discusses architecture principles. However, I truly feel the main goals of a developer are to strive for maintainable and flexible software. Especially when building applications that will be sold for commercial use. I understand at certain times, we just need to put together some throw away code. My philosophy is you don't need to blueprint when you're building an outhouse. At the same time, you don't run down to the local hardware store and pickup some 2x4's, a hammer and some nails to build a building.

    A layered architecture that allows developers to build maintainable and flexible code requires a little more time up front to implement. However if performed properly, as an application grows, the amount of time to implement changes & fixes should be easier to forecast compared to the “software right now” mentality.

    A common practice when learning a new UI technology is to fall prey to an anti-pattern such as the Smart UI pattern. The problem with the Smart UI pattern is there are no levels of separation and code becomes tightly coupled with low cohesion.

    Even though the Smart UI pattern is claimed to be the fastest way to get an application started and initially out the door, as the number of man hours for the project increases, the more brittle the application becomes. The tendency is for new features to take longer and longer to produce and each time the code is touched; the potential for introducing problems becomes greater.

    If you’re a business manager/owner and you are frustrated by the fact every time you ask for a change or have a problem fixed, you end up with more problems. Chances are your developers didn’t take the time to think and follow software design principles when architecting the application.

    Also, it’s common for code to be duplicated which can lead to different areas of an application producing varying results to an end user when the results should be the same.

    Applications that don’t have any type of architecture are typically harder to build automated testing for as well.

    I truly subscribe to the theory that most large applications started out small. Therefore, every application needs to be evaluated before starting to code.

    Design Patterns properly applied to software development principles should allow architects to create templates and map out frameworks that allow developers who don’t necessarily understand the patterns to be productive. At the same time when followed, the process should eliminate some of the more common problems.

    Also, a goal of a good developer/architect should be to develop code that others work in and have a good understanding of what they’ve done.

    To me this, is why I'm so excited about technologies such as WPF & Silverlight which were built to support the MVVM pattern.

    I also think Microsoft has saw the light and understands limitiations of Web Forms development with Asp.Net. There are those who will defend technologies they know until the death. The hard part, especially for business owners is trying to differientiate the real motivation behind technology choice discussions.

    On one hand, there are developers who defend technologies because that's what they know and they don't want to have to learn something new. On the other side of the spectrum, you have developers who want to use every new technology that's released. Neither of these stances are seldom in the best interests of the business.

    I believe as developers, we need to choose tools and technologies that allow us to develop rich applications that solve business problems needed to for our companies to make money.

    So this should be taken into consideration when deciding on what technologies to use.

    Additionally, by using common patterns and principles if planned correctly, applications can be adapted to new technologies when they release without having to always start every application from scratch

    An example would be a WCF service that utilizes the Façade pattern to create a Service Implementation and Business Logic Layer. (BLL) An interface could be defined and implemented by the BLL. Now, the same interface is used to instantiate an instance of the BLL in the Service Implementation Layer.

    To take this a step further, you can implement the Factory pattern and create a class the Service Implementation layer utilizes to generate an instance of the BLL. You can then define assembly values in a config file. Then along with reflection you can dynamically load the BLL assembly and instantiate it inside of the factory class.

    Since the BLL provider implements an interface you can create a new BLL at any time and plug it in

    An example of how this would be useful is if the Data Access Layer (DAL) was originally built using ado.net and you come to the realization that using an ORM would be 70% more efficient and cut down significantly on user errors.

    You make the decision to modify your DAL to utilize an ORM. Since you’ve layered your WCF service, now instead of starting a new service from scratch, you copy the BLL provider into a new project. Then plug in the ORM code.

    Once your implementation is complete, you can copy the compiled assembly to the application’s bin directory and update the config values that instructs your factory class how to load the new assembly. Now your service is using your new BLL provider. The factory pattern let you implement the new assembly dynamically on the fly without requiring the service to shutdown.

    In doing this, you’ve achieved the key goals of maintainability and flexibility. This would be an example of Dependency Injection.

    Here is a link to WCF service template I’ve created to share with others.
    http://www.dotnetpatterns.net/content/190-Base-WCF-Service-architecture

    Also, I've created an article explaining how to build a class for Dependency Injection within WCF. (
    Note, if you need DI with container capabilities, there are several DepencyInjection libaries available. Microsoft has the Untity framework.)

    http://www.dotnetpatterns.net/conten...r-WCF-services

    MVVM

    MVVM is probably the most important pattern I’ve used in recent date. It stems from the Presentation Model pattern. Separating business logic from the presentation logic is extremely important when striving for an application that is maintainable and flexible.

    The MVVM pattern also leverages WPF/SL data binding and Commands which are extremely useful in implementing key design principles of patterns such as the loose coupling/ High Cohesion of application components and the separation of concerns.

    I’ve created a sample template that can be use to build a real world, enterprise line of business WPF/Silverlight applications utilizing MVVM.

    http://www.dotnetpatterns.net/content/185-Silverlight-4.0-Prism-4.0-Telerik-Ribbon-Application-Template

    The Model allows us to centrally implement features such as INPC as well as validation logic in a single place. Then, we can utilize this functionality throughout an application. This cuts down on repetitive code and costly mistakes.

    The View Model allows us to separate presentation logic out of the view which provides for cleaner code, better testing.

    Then you have the View which just contains Xaml which is solely repsonsible for laying out controls that appear on a user screens. WIth this separation, you can allow Graphic Designers to build views and easily plug the views into ViewModels without having to know anything about devopment languages.

    I also use the Prism framework in my larger applications.

    (Please note I’m using the following information as a reference while writing this.

    http://msdn.microsoft.com/en-us/library/ff921146(v=pandp.40).aspx
    • Prism allows us to build applications that follow the composite pattern with the ability to separate our code into Modules. This utilizes the Separated Interface and Plug-In patterns.
    • We utilize modules to separate different functionality of an application. This gives us the flexibility to enable and disable modules to users with relative ease.
    • Additionally, when designed properly, making changes or fixing problems in one module should have little or no effect on other areas of the application. Something that grows increasing hard when apps are developed with no time spent on architecture and the utilization of development principles. So it’s another way we’re achieving our goals of software that is maintainable and flexible.
    • Regions which follow the adapter pattern, allow us to dynamically load views in a loosely coupled fashion throughout an application.
    • Regions, also give us the flexibility to combine individual Views from anywhere in an application into a Composite View.
    • In the Silverlight template, you will note a module will have a controller which follows the Application Controller Pattern. The controller will take care of initializing and displaying Views for a module. It also will coordinate the communication between Views or View Models if necessary.
    • The Command Pattern allows us to decouple Views from View Models yet still have the ability to initialize actions. This allows for a clean separation of concerns and makes it more conducive for Unit Testing.
    • Prism also implements a variation of the Event Aggregator pattern. Personally, I choose to use MVVM Light’s Messenger class for publishing and subscribing events. I feel Event Aggregator and Observer Patterns are closely related.
    Design Patterns to Avoid

    As much as I don’t like the Smart UI pattern, I still can’t say I would never use it. I would more so say there are Design Patterns that should be used with varying levels of caution.

    For example, the Observer pattern as well as the Event Aggregator patterns when implemented incorrectly can lead to extremely difficult to track down issues. Events in SL, when used incorrectly are a common source of memory leaks.

    There are some heavy debates in regards to the Singleton pattern being a pattern to stay away from. However, I feel it depends on how it’s used.

    Also, I not of the mind that Design Patterns should be used everywhere. Design Patterns can lead to complexity and I subscribe to the KISS principle. I think as with everything, you have to learn when Design Patterns make sense and when they do not. I tend to use Design Patterns in areas where I feel there is inevitably going to be a need to support change in code.

    I think a key for developers/architects is to accept the fact that they probably aren't half as smart as they think they are. I believe we start to improve when we open our minds up to the fact that there will continually be ways to improve.

    At the same time we try not to ever give into change just for the sake of change. Also slide into the paralysis by analysis pit either.

    Even when you get to a point in your career and you realize there is a better way. Most of the time setting those changes in motion is seldom, if ever easy. Learning development principles and coming to the realization that Design Patterns can provide solutions to your problems is not an easy concept to grasp for some developers.

    More importantly it’s even harder for business managers/owners to comprehend because all they hear is its going to take more time up front.

    Most are in the mindset of what I call software right now. They want to take ideas and immediately start writing code for them with the sole goal of getting something out the door as fast as possible.

    In my opinion, the flaw with this mentality is failing to realize the software process isn’t finished when the code goes out the door. It’s merely the beginning if your software is successful. You’re going to have bugs. You’re going to have customers request new features or changes to existing features they don’t like.

    Thus the software right now approach usually leads to developers following the Smart UI anti- pattern. In relevant terms of an application lifetime, it doesn’t take long for development to turn mostly into a reactive process. This usually ends up in an infinite blame game loop.

    Development blames the business side because they don’t get proper specs and time to plan. Business owners feel developers aren’t doing their job because the code they turn out becomes slower and slower and usually has more and more problems as it grows.

    At some point it’s hopeful that you come to the realization there has to be a better way.

    If you come to realize the importance of patterns and practices, in most environments, that’s just the first challenge. Figuring out a way to get your message about the importance of architecture principles is an important step.

    Personally, I try to use other industries where architecture is a necessity for any project. Currently I like to use the concept of building a 20 story building. I ask business owners or even other developers if they would be comfortable going down to a local supply store and picking up some concrete and lumber. Then start breaking ground without any architectural documents or planning to go off of.

    I start asking how you would expect to have a high level of cohesion between the different levels of the building if you don’t follow proven principles and architectural patterns.

    Then we usually start getting into things such as the construction of the walls and how we probably need to be able to move the location of walls on each floor at some point during the life of the building. Also, if we’re moving walls are there tight couplings to thing such as electrical and data wires we need to plan for? This gets us into the discussion of Design Patterns and the importance.

    The rest is dictated by where the conversation leads us. The ultimate goal is to help others realize when building software, just like any other form of engineering, you need to justify why you should NOT take the time think plan. It's a different way of thinking but I feel it's critical if you want to stop building the "Big ball of Mud" applications.

    Hopefully more and more developers are getting tired of wading through the swamp. It's up to us to continually educate and be the driving force for change.