Today we are going to talk about one of the most confusing topics of all and see if we can unravel the mess of Dependency Inversion, Inversion of Control and Dependency Injection.

It’s not completely important that we understand the specifics of each of these names, because many people end up using them interchangeably. It’s pretty unlikely that we are going to correct all that in this blog post.

What is important is that we understand the concepts and ideas behind each of these topics and understand what architectural problems each one is trying to solve.

Read more at :

Java Code Geeks: What is Dependency Inversion? Is it IoC?

It is really shocking that there is the need to explain to "professionals" certain architectural patterns

(take the log files parsing example).

It sould take no more than two minutes of thinking (analysis is oversized here) to realize that the if-else solution is not a solution and

the obvious way is to use the adapter pattern.

But I have to admit the if-else cascade is quite frequent in the (large amount of) code I have seen in my career .

There are 2 possibilities:

1. I am an alien coming from another planet

2. There are a lot of developers that would better do another job

"really shocking" == par for the course

It is really more sad than shocking. Most people don't understand good programming technicques let alone architectural patterns. I was doing a code review last week and someone who has been in the computer industry for ... 30 years?... said "What is wrong with my code?  It works and the users are happy."

.. I guess it is shocking that I cannot type. :) 

( #of years != good coding ) || ( #of years != good OOD/OOP )

Lot of people are still in the mindset of if it ain't broken don't fix it! You do come across those so called SMEs that have #of years in the company as their ASSet.

It is not shocking, it is just reality. Most design patterns are used in framework/product development which have to be general and flexible enough to cover multiple use cases. Many developers('Professionals') do just  'business' and less framework development and even more developers do maintainance. So there is no surprise if 'professionals' can not apply design patterns - they just never needed them (or they needed them once in 3 years). And being developer ist very versatile job, applying design patters is only one small part of it. Some are good at design patterns, some at requirement analysis, some at documenting stuff or testing or mediating conflict in the team or at refactoring old code or or or.... My main point is that creating software is very multisided process and there can be 'professionals' without being professional at design patterns.

It is not shocking, it is just reality. Most design patterns are used in framework/product development which have to be general and flexible enough to cover multiple use cases. Many developers('Professionals') do just  'business' and less framework development and even more developers do maintainance. So there is no surprise if 'professionals' can not apply design patterns - they just never needed them (or they needed them once in 3 years). And being developer ist very versatile job, applying design patters is only one small part of it. Some are good at design patterns, some at requirement analysis, some at documenting stuff or testing or mediating conflict in the team or at refactoring old code or or or.... My main point is that creating software is very multisided process and there can be 'professionals' without being professional at design patterns.

 

I can agree that creating a software system requires different skills but I was focusing on the pure code writing.

When you say that many developers just do "business", it seems that you think that business code (i.e. your application domain) is a huge set of "do_this", "do_that", without the need for abstraction/architecture (in broad sense, not only software).

More, design patterns are not for frameworks, they solve common problems in an effective (and really working) way.

You can have the need of singleton, adapter, decorator etc even in business code.

Anyway, my reference to design pattern was just an example of the minimal "tools" any developer should have in his/her head. 

IMHO, O-O developers without O-O analysis/design skill produce disaster. 

it's usually "stranger in a strange land" :-)

it's usually "stranger in a strange land" :-)

Not for Tony Banks ;-)