Design patterns

[minestrone]

I had the task of taking some VB6 / 4GL programmers though .NET on one gig. They had done a month's worth of courses but had very little understanding of OO.

Before introducing any of the GoF patterns, I made sure there was a good understanding of basic OO principles (i.e. GRASP General Responsibility Assignment Software Patterns). Once developers understand this they are most of the way there in my opinion.

There are many applications where patterns are blindly used just because they can be. I refer to these as book-keeper apps: a book-keeper can go through the mechanical process of producing your accounts but only an accountant can advise on the implications.

I think it is pointless teaching OO principles to someone learning how to code. My first permie gig sent me on a design course and the teacher told me that he did not 'get' OO for a few years and I would agree with that now. I used to train developers and made the mistake of trying to get them to understand polymorhism when really it is hardly used now, developers mostly just bolt on classes to frameworks now. It is better to teach them the language first and let them pick up OO after a while. We do not try and teach Shakespeare to a child before they learn how to write a sentence.

 

[lightng]

I think it is pointless teaching OO principles to someone learning how to code. My first permie gig sent me on a design course and the teacher told me that he did not 'get' OO for a few years and I would agree with that now. I used to train developers and made the mistake of trying to get them to understand polymorhism when really it is hardly used now, developers mostly just bolt on classes to frameworks now. It is better to teach them the language first and let them pick up OO after a while. We do not try and teach Shakespeare to a child before they learn how to write a sentence.

They were pro coders with 10 yrs experience. They had worked with the limited OO features of VB6 but not the full ones in .NET.

I disagree that you cannot teach OO to someone learning to code. Look at Java / BlueJ and the objects first approach for example.

 

[lightng]

I doubt any professional mechanics do refer to Haynes manuals. Workshop manuals maybe..

I see it more like saying to Paul McCartney: You don't need to think about what sequences of notes to use in songs anymore because we've written them down for you. So now you can write much better songs in half the time.

Workshop manuals I meant - they're all the same to me as I'm not even a hobby mechanic.

My mechanic has plenty and he is highly though of in this area.

 

[minestrone]

I disagree that you cannot teach OO to someone learning to code. Look at Java / BlueJ and the objects first approach for example.

Well I suppose you can teach it to them but they will not learn it. Better off teaching them something they can pick up and let the OO principles come to them in time.

 

[lightng]

Well I suppose you can teach it to them but they will not learn it. Better off teaching them something they can pick up and let the OO principles come to them in time.

We'll agree to disagree on that one then.

 

[Smurficus]

Well I suppose you can teach it to them but they will not learn it. Better off teaching them something they can pick up and let the OO principles come to them in time.

Some developers just don't get it, never have, never will; on the other hand for some it just clicks. This doesn't seem to have anything do to with experience but just that some people instinctively think in terms of objects.

 

[minestrone]

Some developers just don't get it, never have, never will; on the other hand for some it just clicks. This doesn't seem to have anything do to with experience but just that some people instinctively think in terms of objects.

I think the first part is correct, I would estimate that about 10% of people who go into a career in OO software do eventually get it.

I admit that it was a couple of years before I really got it, I read the GoF book back to front more than a dozen times during that period.

I still think I learn about OO every day after more than 10 years in the job, every design decision I make I question. I just do not think people instinctively learn it with a few days training.

 

[Smurficus]

I still think I learn about OO every day after more than 10 years in the job, every design decision I make I question. I just do not think people instinctively learn it with a few days training.

I would agree that no one is going to know all about OO with a few days training, but nor would they with a few years training.

My point was that for some people the core principles behind OO fit nicely with their natural thought processes improving their capacity to take on things like patterns earlier.

I think any decent developer will agree that you'll always be learning new/better application of OO in development - one reason why I hate looking at old code

 

[lightng]

I would agree that no one is going to know all about OO with a few days training, but nor would they with a few years training.

My point was that for some people the core principles behind OO fit nicely with their natural thought processes improving their capacity to take on things like patterns earlier.

I think any decent developer will agree that you'll always be learning new/better application of OO in development - one reason why I hate looking at old code

A few days training (good training) I would expect the basic principles of OO to be picked up - the GRASP principles. I would also expect students to be able to apply those principles. The course has to be engaging and the fewer the number of learners the better. I agree if its a stuffy lecturer in front of a class then the learning of OO going to be hit and miss.

In one permie job I had, I was hiring a computing graduate for a new junior spot. I was quite surprised that two of three that I interviewed did not understand the difference between a class and an object - I'm not joking. These guys had OO and UML modules on their CV too.

Once the programmer has GRASP principles under his/her belt, six months with good lead developer who involves his juniors with design decisions can bring them on immensely. Patterns can be introduced along the way. I agree it can be years after that before you're considered a "master". There is always the 70/ 30 principle: it takes 30% of your effort to get 70% of the way there but another 70% effort to complete the remaining 30%.