A few weeks ago Uncle Bob wrote a blog post about if/else/switch being a dependency magnet. He recommended reversing dependencies by using polymorphism, and he chose a factory pattern to do that. It was a very useful post, and I completely agree with its main point, but it got me thinking - do we really need factories for that?

Sometimes we need to transform JSON files from one schema to another. These transformations can be straightforward, or there can be complex rules. This is one of the problems developers usually solve by writing procedural code, even in object oriented languages. . .

You are happily coding. You are in the flow. You have a cup of coffee next to you, and object oriented code is flowing freely. Suddenly, you have a String of JSON data, and you need the value of a certain field inside. . .

All tests have the expected part and the actual part. Tautological tests are tests where expected and actual parts are equivalent in some respect such that it makes them useless or meaningless in that respect. Isolation by mocking makes tests tautological.

We know we can eliminate controllers, services, factories, managers, helpers and other obscure technical "objects" which don't exist in the real world. Can we eliminate "collection objects" as well?

Persistence is one of the most difficult and confusing problems in object oriented programming, which, it might seem, will never be solved. Databases are about individual rows of data, objects are about individual instances of behaviour. It is not obvious how they can be mapped. . .

It just so happened that lately I have been hearing quite a bit about "contracts" and how good they are at keeping modules decoupled. The argument goes something like this. . .

I want to sell strawberries.

If you read Elegant Objects, you probably know about vertical decorator pattern. However, there are right ways and wrong ways to do it. In this post I want to propose a few additional rules I haven't seen in the book, even though I think they are there implicitly. . .

There are a lot of articles and posts and Stackoverflow answers about why Java static methods are bad. Most of them are valuable and describe real problems. However, most of them are either non-essential or non-concrete, and none of them have pointed out and described thoroughly the fact that. . .

Domain Driven Design is a very useful approach to software development. The idea is that developers should not begin modeling their applications in terms of how the application will work technically, instead they should model the problem domain itself. . .