Reply to: Design patterns

[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%.

[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

[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]

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.

[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.

[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]

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.

[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.

[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.

[TheRefactornator]

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.

Please don't, he should not be encouraged in any way. Not even in jest.

[VectraMan]

Thats like saying you've got no business fixing cars if you need to need to look at a Haynes manual. What a load of tosh!

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.

[lightng]

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.

[lightng]

Most design patterns are common sense / good practice anyway.

I used to work with a chap who was always spouting off about one type of pattern or another. I had a look in his book to see what the tulip he was yapping about, only to discover that I'd been using similar designs for years - I'd just used my brain and figured it out myself.

Most decent old skool software engineers won't waste their time or money on such books...

HTH

Thats like saying you've got no business fixing cars if you need to need to look at a Haynes manual. What a load of tosh!

[FSM with Cheddar]

Agree with Smurficus.

It's a common language.

Also, when an architect designs a new house, they don't start from first principles, they use their experience and a number of basic design principles.

Software is no different. If you stick purely to patterns then you well stifle any creativity, however if you ignore what has already been done before, then you are wasting time.

I find the book of anti-patterns more useful, as it reminds me of design routes to avoid.

[Smurficus]

or if their code just falls into design patterns by complete accident, because good code will do that and the patterns documented by the GOF and others later are just statements of the obvious.

A good, experienced developer's code will tend to fall into patterns as they've done the trial and error themselves, this is the same reason GoF seems obvious. I see design patterns as a way of harnessing this work and passing on the information without the need to go through the trial and error again.

Patterns also provide benefits, other than code reuse, that architects and developers should be promoting:

• better communication - if all developers in the team understand what the strategy pattern is for then there is no need to describe it in detail and invite misinterpretation.
• faster training - junior developers learn from the more experienced, if everyone is talking a common language the juniors will be able to skip parts of the trial and error that those more experienced developers have had to go through.
• there are more, I just can't think at the moment...

I think that, like everyone else, they have a place in the developer's toolbox but they are far too commonly abused.