In the first post in this series (table of contents) I explained why agile software development influences the choice of the UI design pattern. For short, changeability and extensibility are must have characteristics.

In this post, I’ll show you the corner stones of a UI design pattern that fulfills these needs.

Principles of Object Oriented Software Design – SOLID

One of the best known set of principles to achieve my goal of a UI design pattern that is changeable and extensible is SOLID by Robert C. Martin (link).

If you don’t already know those principles then please follow the above link and read it before continuing here.

The principle I’m most interestes at the moment is the S in SOLID, the Single responsibility principle:
A class should have one, and only one, reason to change.

.NET, Agile, Architecture .NET, Agile, Architecture, Design, User Interface

There are a lot of patterns available for UI architecture: Model-View-Presenter (MVP), Model-View-Controller (MVC), Passive View, Model View View-Model (MVVM) and some more.

However, none does really fit my needs in an agile project.

In this series, I’ll show you first why they don’t work for me and then I’ll try to evolve a pattern that matches the special needs in agile software development.

Why is Agile Software Development different?

In agile development, we start little and add small parts to evolve a complete application. This approach allows us to deliver every sprint (= iteration in Scrum terminology; 2 weeks in our case) a working software and  to get early feedback from our customer.

When we start a project, we don’t have a complete requirement specification (nor do we want one). The requirements (or user stories in Scrum) evolve together with the software: appetite comes with eating. The requirements get clearer and more precise as we learn more about what the software has to do and how we can implement them providing best user experience.

.NET, Agile, Architecture .NET, Agile, Architecture, Design, User Interface