In the last two posts of this series (table of contents) I explained the need for a new UI design pattern: changeability and extensibility.
In this post, I’ll throw a big diagram in your face without much explanation. The reason for this is that I want to give you the big picture before I start digging into details in the following posts of this series. You can always come back here to see where we are.
The Big Picture
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...
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...
The Model View View-Model pattern gained a lot of momentum lately. It allows to reduce the code in the code behind class of a form or user control to a minimum. Therefore, unit testability is improved dramatically compared to other view patterns like MVC/MVP. However, when I design software, I follow (amongst others) the principles of SOLID (link). The first principle in SOLID is the Single Responsibility Prinicple (SRP) that states that “A class should have one, and only one, reason to...
These are my personal top ten of software design evilness. That means ten designs that make your software either complex, untestable, monolithic, unchangeable or hard to understand:
Singletons
Enums (or other c# enumeration equivalents)
Swallow exceptions
God classes
Missing interface segregation
Monster classes
Too configurable, too flexible
Abstraction layers not providing additional abstraction
Try catch for program flow control
Missing logging
I’m often hearing thoughts about Test Driven Development from people not using it, which are not true (at least not 100%).
Therefore, I want to describe some of these myths here:
Writing unit tests is difficult and complex
Projects take longer because of the additional test code that has to be written
Not everything can be tested with unit tests. Therefore TDD cannot be used.
There is no need for architecture and design because TDD claims to evolve that from tests
Yesterday, I found an interesting page (in German) describing some of the most important patterns and practices in software development: Although I’m not a fan of wrist bands (see the linked page to see for yourself), I like the page for its short description of patterns and practices like: Don’t repeat yourself keep it simple stupid single responsibility pattern separation of concerns interface segregation principle dependency injection principle Liskov substitution principle open close...