An Old Antipattern: "Too Much Architecture"

  • Article

 At  least in Software Engineering, but I guess the same applies to other sciences, there are ideas, concepts and paradigms easy to understand, but not so easy to implement in practice

I remember, for instance, I understood very quickly OOP. It was pretty clear that Bird, Dog and Cat were subclasses of Animal, and that SiberianHusky or Labrador where subclasses of Dog, while Parrot was a subclass of Bird

But then I was unable to write a piece of OO code that takes a number and tells if the number was even or odd. I mean, I did it. But I made a one-class application with a method, not so different of a simple C language function bool IsEven(int a)

I have no doubts about the need of OO and its benefits over structured programming. I want to highlights that at the same time OO design is by far more complex

So Design Patterns came to the rescue, with a toolbox of pre-molded components, still unfinished from the point of view of our application, but with a very clear separation of roles and well established relationships between participant classes of every pattern

First, I borrowed the GoF book. Then I bought it. I read all the more than 20 patterns, Creational, Structural, Behavioral... I understood everything again. I figured out scenarios where to apply each one of them...

And again when I had to start... Wow... Again my mind empty. It seemed clearer at the book

After that first stage, I entered to the next one: try to make patterns fit everywhere. The more patterns in, the better... I made beatifuly complex applications I was unable, in best cases, to explain. In the rest of cases, I was unable to finish them

Of course, again, the problem wasn't Dessign Patterns, but how easy was for me falling in the temptation of abuse. Like with any medicine: who exagerates the dosis, turns the remedy into a new disease

Nowadays I see two other adictions:

  • The need to adopt immediately the new version of everything (.NET framework, Spring framework, Eclipse, etc) without actually considering if its benefits are helpful for us (in several cases, without knowing which those benefits are. I insist: I'm not against modernisation but the fact of forgetting the last instance business goal (the forest) while being so concentrated just in a new technology (the tree)
  • The other adiction seems to be Object/Relational Mapping (or O/R-M). As with OOP, design patterns, etc I repeat over and over: I'm not against O/R-M! What I want to mean is: if then, as I saw in so much forum threads, yo will be wondering how to do to avoid loading a complete object graph of nested elements just to show a simple table in an ASP.NET page, check how ready you were to get on O/R-M and if it's true that nowadays mappers are the solution you need or just a new problem you gotta solve

I want to show a dialogue kept in an architect forum at MSDN: please click here

https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=630361&SiteID=1

The post is about problems derivated of O/R-M abuse. Just an example in thousands about how "easy" is to choose "the difficult one"