I haven’t been able to do much coding this year, and my blogging frequency has also decreased dramatically. The reason for this is we bought an old crappy house, tore it down, and then built a new one. Almost all of my free-time is consumed by planning, organizing and doing stuff in and around the house. I’ve spent most of my summer with shovelling and moving earth, sand, dirt and aggregate and building things with concrete. Now that it’s winter, work is moving indoors, and I’ll be busy making furniture for the next few months. Fortunately, there was still an opportunity to write a little code, and it even involved the construction activities. The house we’ve built is of the prefabricated kind, and we’ve actually built two of… Continue Reading…

The singleton design pattern ensures that a class can be instantiated once only. It provides easy access by means of a global operation that returns this single instance. Definition of the singleton design pattern A large portion of the programming community has recognized the singleton design pattern as an antipattern that is best avoided. This recognition is strong enough that most developers won’t touch a singleton with a ten-foot pole, even if their lives depend on it. I have a problem with most extreme opinions, mainly because they are usually quite wrong. And this is one of those, a pseudo truth that is being repeated over and over again like a prayer without questioning. Some high deity in the form of a prominent developer once spoke it out… Continue Reading…

The creation of objects is one of the most popular topics in software development. It’s that popular because there is a vast range of possibilities and almost every road leads to Rome. But different projects have different needs, and the same is true for organizations and target audiences. Whatever works well in one spot may be either too complex or too crude in another, and here is where things get tricky. Developers have to have a good understanding of the requirements and how the code will eventually be used. And that has to happen before the actual object creation mechanism is planned and implemented. In the world of dotnet, the most common way of creating an object is calling a constructor. This is as simple as it gets,… Continue Reading…

I have recently changed my job and there’s a lot to wrap my head around now. My new employer is about 250 times larger than my previous one, and apparently, there comes a lot of change with that size. For starters, I am now officially called a software architect. I did successfully complete a software architecture program in 2018 with my old employer, where I was also certified as a software architect, but my designation didn’t change, and I kept being an ordinary software developer. To be fair, this never even bothered me, since my job didn’t change at all with the certificate. If you work on client projects in a mid-size software house, you’re doing the full stack of the job anyway, and every one of your… Continue Reading…

There is a follow-up post: Advanced weapons of mass construction Last time I wrote about how to use interfaces to their full potential, but I never really mentioned factories beyond the fact, that we probably need them. This is going to be another chapter to the previous post with a more in-depth look into the matter of encapsulated object creation in C#. Again I will start with what I usually find in a client’s project, and then I will move in small steps towards a progressively more mature implementation. Every step will include a bit of code to demonstrate the changes that were made. Making up a good example to demonstrate factories is surprisingly hard. There is a multitude of possible scenarios available, but most are too complex… Continue Reading…