Patterns matter... everywhere

Many years back, when I started learning OOP and design patterns, I thought that those complex and probably cool things have to be implemented in some really large application to provide all the benefits mentioned by GoF and shine in all their glory. Some kind of distributed infrastructure, dozens of developers in team, thousands of clients, daily changing requirements that demand highest application maintainability — in my mind something like this was the least conditions for even start thinking about those "patterns". And since for that time I had been working on content-oriented ASP.NET MVC websites built on Umbraco CMS, there was very little opportunity to use those patterns. You have got controllers, you have got boredom services/repository approach implemented by LEAD OF THE TEAM who wrote FIRST HUNDRED LINES OF CODE for the project — that means your work is just CRUD things as uniformly as it is possible, no step aside allowed, cover that with tests and be grateful to Universe.

And I was grateful to Universe indeed because, amongst many other good things in my life,  it let me to know about Zoran Horvat, c# courses author, whose storytelling of those design patterns just blew my mind. His manner of explanation was exactly that I was needed — a course about how to create objects, a couse on how to build behavior upon them, how to separate concerns and eventually — how to manage overall complexity of the whole application. Without any rush, diving into deep details of each example, Zoran Horvat's courses literally gave me opportunity to catch a lot of "aha!" moments while working with his courses - invaluable.

Working with ASP NET MVC and Umbraco, I saw patterns in their design. It becomes obvious when you use them — you see how they work, what they provide to developer and where they let them to extend their built-in functionality. I started feeling those patterns somewhat intuitively; and also I wanted to build something really big with them but... nothing big had been observed on my developer's horizon.

So, with hard breathe, one day I started to write some small utility — the tool that we needed for the project. It was something about 3 hundred code lines application for very specific task to be used once in a while by our QA team only - nothing really fancy. The purpose of that command-line tool was to fill up the database with number of business entities following particular testing pattern — this many entities with address from UK, out of them that many entities of types 'stakeholder', 'communication' etc.

And how big my surprise was when unexpectedly for myself, planning implementation for that application, I found my mind suggesting me some of those patterns! Separation of concerns, dependency injection, factories, singletones, chain of responsibilities and even visitor naturally found their place in that small application. Ancient wisdom came true - "whatever is in big, there is in small". I was so satisfied doing that 300-liner :)

Interestingly enough, I caught myself on the thought that sometime I even can not recall specific name of the particular pattern that I'm going to use for some scenario. I even don't need to recall its name to implement it — I simply put it into code and that works fine.

Later on I had same situation on another project where I was upgrading Umbraco CMS web site from version 8 to 10. The main problem of such upgrade is the fact that Umbraco 8 was written for .NET Framework, but Umbraco 10 has been upgraded for .NET Core. That means a lot of api changes in the application code, so the task itself was quite big. There is also difference in how the content is stored in database - Umbraco 10 uses much more lightweight JSON objects to store data in the db table. Moreover, content on the old site was implemented using particular extension package, which had been deprecated by the time of Umbraco 10 release, since its functionality has been natively included in the newer CMS versions. So as part of that work I (again!) needed some bespoke content upgrading application that simply traverses the content tree, picks items one by one, looks their old type id, changes it to respective new type, updates format of property values and saves back into the db.

And (again!) something that I call "thinking in patterns" came in use naturally and gave me joy of nice solution of that not so complex task.

With time and experience, it has been making more and more sense to me, that to use and implement design patterns you don't need to await for some sacred moment working on some ground-shaking application. Design patterns really can have their natural place even in small simple software tools.

As it has been said — it is not about the bow and arrows, it is about the archer.