I saw an article (well more of a rant) the other day, by Rob Williams Brain Drain in enterprise Dev. I have to say, I do agree with some of what he is saying. I know from my personal experience, I had spent a good 2 or so years just wallowing in the enterprise development world, not learning anything and actually losing my skills I developed before. The corporate confront zone is not conducive to eager technologists.

In this article he also stated: 

"1 in 10 cant even pass a simple test like ‘which design pattern is used in the streams library that makes BufferedReader interchangeable with a FileReader?'"

I also tested it at work and I only had 1 out of the 8 people asked that got it right

Without much confidence, I had guessed Decorator based on "interchangeable". I then decided that was actually some worth sneaking into future interviews, and probably a good time to revise a little. 

So I went scouring the internet to find all I could on the topic and I didn't actually find as much as I thought I would. Most of it came from BalusC at Stackoverflow, the rest was very scattered between blog posts, java ranch, some old pdf's and articles I had. I didn't take every single example of every single pattern I found, but rather the common ones.

This may be a good way for people to learn about patterns, quite often they are using them everyday without realizing.

Read more at :

Design Patterns in the JDK - Java Code Geeks

Well, while one can use a BufferedReader to _decorate_ a FileReader, if I "interchange" a BufferedReader with a FileReader then I'm actually plugging in a different stream reading _strategy_, so the strict answer to your question would be the Strategy pattern.

Thinking about this a bit more, it's one or the other or both depending on where, how and when the interchange happens, so definitely a good interview question :-)

Interesting thought.

Delineation of the patterns is probably more important of the nomenclature, but awareness... i guess sometimes I wonder about whether it's really important for us to do stuff according to patterns as opposed to just getting it done.

Got me thinking, though. Good job.

Hi.. Can anyone let me know which would be good reference books for learning "Design Patterns". I have planned to take up my architect exam.

Any reference links would also be helpful.

Thanks.

I am so sick of hearing people talking about design patterns is like a must know for all programmers.  I will take anyone that can write good clean code without using any design patterns.  I've seen too many programmers use design patterns that clearly doesnt needed.  Or worst, use wrong pattern to solve a simple problem.  

I partly agree with Bill. Design patterns should be studied, however they should be used as a common language when describing/documenting code not as a literal 'how to' for system design.

They are things that you recognize.

I am so sick of hearing people talking about design patterns is like a must know for all programmers.

They are not the first (nor the last) cargo cult.

Peace,

Cameron Purdy | Oracle Coherence

http://coherence.oracle.com/

I am so sick of hearing people talking about design patterns is like a must know for all programmers.

They are not the first (nor the last) cargo cult.

Peace,

Cameron Purdy | Oracle Coherence

http://coherence.oracle.com/

Cargo cult.. LOL. Nice one.

Agreed. Can we just say that programers that write good code will probably use design patterns, even if they don't know it? After all, isn't a design pattern supposed to be an abstraction of a good practice? Otherwise it's meaningless.

-Laurent

http://www.jppf.org

So what?

I've been a software engineer for about 15 years and I wouldn't have known the answer to that question either, despite the fact that I must have created an untold number of "decorators" in my time.

And why? Because it's a bulls*it question. It's a question invented by geeks of below-par intelligence to make themselves feel important. What's this pattern?

    i++;
    
Don't know do you? Well it's the "numeric incrementor" pattern. See, I am far more intelligent than you, and what's more, since this is an interview, you don't get the job either.

There is no wonder that people are abandoning Java is there? I mean, I have to actually waste brain cells on remembering this garbage just to get through interviews conducted by these morons. Next time someone asks me that question I think I will decorate their face with the pattern from my knuckles.

To anyone else who is really just absolutely sick of this nonesense, I would suggest learning Scala. Apart from (IMO) being the power language of the future, one of the great things about Scala is that because it's a step up in complexity from Java you have to actually be intelligent to use it. Nobody in the Scala community has time to waste thinking up the next geeky name for something completely trivial - they are far too busy trying to understand what continuations are.

And finally, I just have to say that recently the articles on TSS recently have been so unbelievabley poor it's just untrue. I really need to stop reading this site...

Because it's a bulls*it question. It's a question invented by geeks of below-par intelligence to make themselves feel important.

Patterns have very little to do with elegance, performance, "geekiness" or intelligence. It's about maintainability and an effort to frame a common design "language". If you are handing an implementation over to some other developer or bringing a new developer onto a team, you want to have some way of saying "this is implemented in this in that way" and have that developer know what to expect, where to start looking and have a good idea about which part of the code does what. Similarly, if you take over someone elses code, it's nice to be able to look at it and recognize the structure and be able to follow and predict executions WITHOUT having to run a full debug cycle.

If it's the word "pattern" that gives you the willies, think of them as "conventions".

If you still haven't figured all this out after 15 years in this industry, you must be thick indeed.

To anyone else who is really just absolutely sick of this nonesense, I would suggest learning Scala.

That doesn't even make sense. Will you STOP using Scala once it's established enough that "patterns" start to emerge and become agreed upon in the Scala world? Because believe me, they will! Either that, or Scala will fade away inte obscurity because once ANY language that aims to be maintainable on any kind of scale needs conventions and a common terminology to describe it.

...I really need to stop reading this site...

Yeah, that'll show em! Really gives weight to your argument.

Patterns have very little to do with elegance, performance, "geekiness" or intelligence....

I take your point about having a language to describe code structure, but my point is that this has been taken to ridiculous levels. We are now giving "geeky" (and I stand by "geeky") names to extremely trivial structures. This in itself is really just silly. To me, when people start to do this type of stuff it's obvious that they're just trying to display some kind of higher pseduo-intelligence and most people can recognise this as a manifestation of their insecurity. Well, as the article says, 9 out of 10 can anyway.

Anyway, this isn't really a problem to me, if it makes the 1 out of 10 feel better about himself. The problem comes when we start to use this as some kind of measure of intelligence and ability. As the author says, he is thinking of sneaking this into his interview questions. This is absolutely typical of interviews for Java jobs. There is hardly any emphasis on the most important aspect of engineering, which is the ability to decompose real world problems into logical software solutions, rather there is just nit-picking over some obscure technical terminology. It annoys me that some geek comes up with a new name for something engineers have been doing for years (as if he "invented" it) and then I actually have to go and waste my time to find these things out, just to get a job.

Dependency Injection is one of my favourites. I mean, this is something that is one of the most fundamental concepts of engineering. It is just a completely trivial construct, but now you have to know (for what bizarre reason I have no idea) that this trivial thing is called "Dependency Injection".

If you look at the Java community now, it is completely bogged down in frameworks, huge complexity for performing simple tasks and (as we are discussing) saturated with silly jargon. To the inexperienced this all sounds great and powerful and so on, but those well initiated into it can see it for the complete mess that it really is. The rats are jumping from the sinking ship because the community has lost the ability actually write code, and trying to cover up that fact with silly names is just not going to cut it.

My point about Scala is that the community does not have this same attitude - yet. They are much more focussed on actual problem solving, whereas the Java community are more focussed on inventing problems that don't exist and then "solving" them in the most complex way possible. Maybe the Scala community will one day go that way too - I don't know. But for now it's not like that. And I think this is partly to do with the language itself. Because it's more difficult, the community is not swamped with self-declared "experts" from which I believe most of this nonsense arises, rather you really do have to be an expert. And those who truely appreciate succinct, precise and inventive engineering do not need to crow that they know the latest name for tying their shoelaces, they just get on with it and do it.

To me, when people start to do this type of stuff it's obvious that they're just trying to display some kind of higher pseduo-intelligence and most people can recognise this as a manifestation of their insecurity. Well, as the article says, 9 out of 10 can anyway.

I don't accept your premise. I'm sure there are some people out there who ask interview questions without a valid purpose - as I'm sure there are some bad developers out there who are just that, bad. I don't agree that this reflects in any way on the validity of patterns. And I don't think it has been taken to a "ridiculous level". Someone as experienced and weathered as you shouldn't need more than 2-3 days of research and reading to get fully up to speed on all established and accepted patterns. I don't think that is excessive. And patterns are not the scourge of Java, as you seem to imply. They have been around long before Java and will still be around long after.

If I'm interviewing a developer (which I have done quite a few times) and I ask about knowledge of patterns, it's not to project intellectual superiority. It's to gauge if this person can be let loose in the codebase without wrecking the structure to a point where it will be difficult to maintain. And for the record, I don't ask the question every time as there are more ways to figure out a developers level of expertise. It's more of a "kicker question" to use when in doubt. And if I'm on the fence about someone and he or she can't properly outline how to achieve extensibility through Strategy-based design or how a Builder can mitigate the impact of future interface changes then I would probably not recommend that person, certainly not for anything above a junior entry-level position. I would question if he or she has the ability to produce robust and maintainable software.

So what you appear to think of as "bad attitude", I call maturity. Enterprise development is not about results, now, fast - it's about maintaining a system across an entire lifecycle - something that can span decades. It's about saving a thuosand hours of several years, not about saving 10 hours this month by not taking the extra time to align your solution to what other people can predictably understand.

Yeah, that was a bit harsh, my apologies. I was trying to be cute but that was just rude.

I stand by the sentiment though, I would expect more from someone as experienced as you.

yes, people should work on all different languages than just java.

- http://programparadigm.blogspot.com/

25 years. I read it and was like, ok, so what? Do I go get the GoF book out, open the IO javadoc and start looking for a pattern that gives me credibility at the coffee pot?

-bk