Andreas Schaefer's Blog

Patterns: Not with Me

Yes, I have to admit I do not use patterns and I hardly know any of them. Seven years ago I bought the book "Patterns in Java" and looked at it only to find out that most of them I already knew and had already applied. So this book went to the shelf to remain there until, I think, it was recycled. So far I never needed patterns to do my job and for most part there are no patterns that deal with multi-threading, class loading and bytecode manipulation (AOP).

But, no, I do not condem nor to I encourage developers to avoid patterns because they can improve their coding and communication skills. Nevertheless I think that everyone has to try hard to understand the background and motivation of a pattern rather than just applying them unchallanged. A pattern is like a cook book recipe and you master cooking when you can change the recipe or mix recipes to a new one and the meal still tastes great because then you understood the recipe rather than just followed the list of ingredients and the instructions.

The only way I used pattern lately was to check out if a company I had a job interview with was really inovative by stating that I do not use patterns. If a manager or a team lead could not accept that I went beyond the need for patterns then it told me that they cannot let developers run loose like I was used in open-source projects and they were quite conservative in handling a project. I cannot imagine that Steve Jobs (yes, I hate his arrogance but like his management style) would have followed a pattern when designing the iPod or do you?

Finally, in some of these interviews I was asked what was my favorite pattern which I find quite an odd question because I would apply a pattern that suites the problem rather than try to apply my favorite pattern. There isn't a HAMMER pattern that makes everything to a NAIL luckily otherwise most of us would be out of a job.

Have fun - Andy

Comments

• "So far I never needed patterns to do my job": whether you want it or not I'm pretty sure you used them. You say it yourself: "only to find out that most of them I already knew and had already applied". When I first read Gang of Four's book I discovered that I already used many patterns without knowing it. That's why they are patterns after all, because they are common sense solutions to common problems. I don't like to read source codes abusing patterns, making it unecessarily complicated to read, but I'm convinced you can't work without never using one (or you're trying very hard :). I wrote a similar story for JavaLobby (http://www.jroller.com/page/gfx/20050424#i_plead_guilty).

  Posted by: gfx on September 09, 2005 at 02:21 PM

• I agree. Patterns should be used as a guideline. Patterns fit many, but not all, problems presented during programming. Some programmers new to Java believe that a pattern needs to be used for EVERY solution; this is not true. It is easy to see where things are made overly complicated due to the overuse of patterns in many applications today.

  Patterns should be likened to refactoring - there is a big return up front for refactoring / using patterns, but at some point the returns are quite diminished. Use as needed, and use not more.

  Posted by: phlogistic on September 10, 2005 at 09:12 AM

• totally agree :-)

  Posted by: akshath on September 10, 2005 at 10:29 AM

• It seems to me like you've missed part of the point of patterns. Patterns aren't necesarily about standardizing implementations as much as they are about defining a higher level language for communicating about implementations. When I'm talking to a fellow developer and I know that they know patterns, I can talk about implementations using the patterns as a reference. I don't want to have to describe the pattern's details every time we talk about it, I just want to use the pattern for reference and spend our time talking about the important stuff - how it's different. It saves much time and confusion.

  Posted by: ferr0084 on September 11, 2005 at 07:35 PM

• Well said, far too often we see people (and especially people who either never have written code or have been sequestered in their ivory towers of architecture for too long) force patterns (and UML, the two seem to go together) whether useful or not.
  They seem to be under the impression that if you just use pattern X religiously (and of course produce enough UML diagrams) all your problems will evaporate.
  Worst case of this I encountered was an architect who was extremely fond of factory patterns and multi-tier systems.
  He'd divided the system into 3 tiers, each of which was itself divided into 3 tiers which each was divided into 3 tiers.
  There were factories for everything, including factories (in some situations you ended up instantiating 3 or more factories to produce a single object instance, and you had to do that for everything that passed any layer boundary so if you had something to read from the database and display on screen you ended up instantiating several dozen objects simply to pass the request to the database layer and back up to the display layer.
  Suffice to say performance was abysmal, and maintenance was a nightmare.
  Think about needing 72 hours for a full build, a printrun of a thousand records requiring 24 hours or more to complete (and producing 1 sheet per record using a highspeed laser printer which can print that much in under an hour if it gets the data fast enough).
  Think about a million lines of code for what should have been a simple CRM and automated mailer application.

  I lost my appetite for patterns there and then. While I do use them, I won't use them for the sake of using them which seems to be what Andy is talking about.

  Posted by: jwenting on September 12, 2005 at 12:19 AM

• very nice... :)

  
  more about that freedom spirit in the description of my project: https://cejug-classifieds.dev.java.net/

  best regards,

  Felipe Gaúcho

  Posted by: felipegaucho on September 12, 2005 at 04:49 AM

• Yes, Steve Jobs most likely did follow patterns. There are human engineering techniques that people follow to develop interfaces. The most interesting part is that most developers are unaware of these techniques, and that is why most GUI are horrible. The fact that Steve Jobs followed the techniques is why his products work. (For most cases Jobs does a great job, but I still have some grips with the Apple interface).

  Posted by: malcolmdavis on September 12, 2005 at 05:29 AM

• Well said Andreas. I also believe that patterns can be helpful and useful, but think people have become too religious about them. I don't think that saying "everyone has used one or more patterns" validates anything. That's why they are called "patterns". Patterns get identified, not created (in my opinion).

  I don't think it's necessary for people to feel obligated to be able to quote every pattern, like preachers quote chapter and verse of the Bible. That's an academic exercise that many don't have time for.

  Too much of anything is bad, including abstraction. Between Patterns, Frameworks, Agile Development, blah, blah, blah, the conversations have gotten *so* abstract that it's hard to tell what people are really talking about anymore. ;)

  -jbob

  Posted by: jbob on September 12, 2005 at 05:55 AM

• The solution should be as complicated as it needs to be, but no more so.

  I think we could all use Ahkam's Razor a bit more during development.

  Posted by: grabity on September 12, 2005 at 06:41 AM

• The point I take is to attempt to understand the problem before you in terms of proven reliable solutions (patterns) and have good reason to not choose a tried and true way due to specific current requirements. Know why you choose to write the code you write. I began Java programming on my own as a programmer with limited experience and with little time to explore the "best" (or even better, proven) way of doing something. I took-on concepts from the language (and related online tutorials) as I learned the language and the API. The notion of patterns was unknown to me. I have recently been working with a much more experienced programmer who introduced me to patterns but did so with the notion that they are not absolute. (This is good because I absolutely don't believe in absolutes.) I have begun to explore patterns as a way to further my programming experience but I do think that my initial simple understanding of Java kept my programs simple. There is the potential to vastly complicate things by blindly applying patterns as a previous post detailed.
  

  Posted by: mjash on September 12, 2005 at 06:48 AM

• But I am not hate patterns and think they have their place where they are needed.

  Apparently you am not needing English grammar patterns neither.

  ...I think that everyone has to try hard to understand the background and motivation of a pattern rather than just applying them unchallanged.

  The challenge of patterns is in how to use them effectively. Like language, they are primarily a means of communicating complex ideas, a set of common idioms, if you will. Mastering them shows an interviewer that you have the willingness and ability to master complex concepts. Merely stating that "I don't use 'em" could mean that you're a hack, kind of like someone who posts a blog entry with numerous spelling and grammatical errors. They could be capable, but you just can't know from their presentation.

  Get it?

  Posted by: gbarton on September 12, 2005 at 07:12 AM

• Hallo Andreas,

  Excellent post! It would seem from the recent java.net poll, you speak for a fairly quiet majority of developers. I am definitely in your camp.

  I am surprised by the pro-patterns responders; they seem to consider patterns to be 'high-level' or 'complex' abstractions. I could not disagree more. To me patterns are akin to 'assembly language;' useful primarily for quickly tiresome discussions of mundane minutiae. Even simple designs can involve dozens, if not hundreds of patterns.

  The only time I see the study of patterns helpful, is for the edification of inexperienced developers. After a few years as a developer, most people have effectively invented all the patterns in the Go4 book, and many more. Things learned by invention, are understood far more deeply than things presented in a book.

  John

  PS Pay no mind to rude responses. Some people feel that when no objection of substance can be made; attack the grammar, spelling, or punctuation. Tschüss!

  Posted by: cajo on September 12, 2005 at 08:19 AM

• Good post, not afraid to say 'the the emperor has no clothes'

  The only thing as dangerous as saying 'do not use patterns' is saying 'you must always use patterns'. Being dogmatic does not help good code.

  I think part of the skill in development is knowing what solutions have been used before , and how you can reuse and improve on them. The solution could be a pattern , an article or even an open source framework - all tools in the developer toolbox, available if required.

  Paul
  www.firstpartners.net

  Posted by: paulbrowne on September 12, 2005 at 08:56 AM

• In my experience patterns are quite effective tool in conveying ideas about design to coworkers. I think though that sometimes programmers new to patterns tend to find there newfound technique a place in their current work to eagerly. But I would not want to dismiss patterns as a tool in software design. I would much rather say to coworker 'Why don't you try using Strategy pattern' then say 'Take a look at this UML diagram I spent 1/2 hour drawing for you'. Of course sometimes a single or unchanged patterns does not apply well within a design, then I'm forced to use heavier artillery like UML (but still pattern terminology might come in handy explaining it). I do agree that over patternizing is a bad idea.

  Posted by: gretar on September 12, 2005 at 09:28 AM

• So you don't use Singletons or Factory objects in your code ?

  How, pray tell, do you try to ensure that there is only one instance of an object within the VM ?
  

  Posted by: martinsmith on September 12, 2005 at 11:36 AM

• Hell yes, but thanks for the opportunity to show that patterns are not a ticket for mindless software development.

  I am using Singletons and Factories when they are needed. Nevertheless even Singletons do not warrant that there is only one instance per JVM. As you may no a singleton uses a static member which means there is one such member per class and so if a class is loaded by multiple class loaders you end up having multiple Singletons. This shows that a pattern cannot be applied blindly.

  Posted by: schaefa on September 12, 2005 at 11:54 AM

• It seems like something is missing from this discussion. As far as I understood it, patterns are discovered as common ways to approach a certain type of problem. You need to sort a items in a data structure, but you don't want to be forced to use one particular algoritm for sorting--so you re-route the sort to use different segments of code that encode the algorithm, or part of it, like the comparison. You can do that in *any* programming language, and the pattern for that is a Strategy. People have been doing it for decades, now we have a name for it. You have someone else's API that has taken you a full week to get anything done with, because you have to call a dozen methods in the proper sequence to get anything done. You write some code that encapsulates those 12 calls in a much smaller API that suits your needs. You've written a Facade. What is the argument *against* this? The point is that you really can't argue with it. You can decide not to use the names that the GOF proposed, you can talk about your design however you want. But if you agree on a common language, then a full-time COBOL programmer can understand what you mean when you talk about a Facade, an Adapter, a Bridge, a Strategy, even if you program in Java or Forth. I'm pretty sure that if you toss the GOF patterns out the window you will still be doing something which, to any other eye, would look like you were following patterns. It's Platonic in that sense, it refers to some level of concepts which cut across individual instances of programs in the world, and, if it applies, it just applies, no argument about it. Cheers! Patrick

  Posted by: pdoubleya on September 12, 2005 at 01:08 PM

• Agree 100% with your point on Singletons which is why I added the words "try to" to my response above.

  Your response has clarified the intent of your original article a little for me. It appears that you are arguing more against the misuse and/or mindless use of patterns rather than their use at all. I agree with you that the misuse/mindless use of patterns is an increasingly prevalent issue.

  Posted by: martinsmith on September 12, 2005 at 01:12 PM

• What is the argument *against* this?
  The argument, pdoubleya, basically boils down to this:

  Somebody: "I'm using pattern X."
  Andy: (Pick one)
  "Sometimes that pattern isn't valid! You're blind!"
  "I already know that so I don't have to call it X! I'll call it Foo! Haha!"
  "People who use patterns are st00pid and I never work for them!"
  "My 'I don't use patterns' fu is unstoppable!"

  That about sums it up.
  

  Posted by: gbarton on September 12, 2005 at 01:55 PM

• 
  Gbarton, the problem is akin to an organization saying "Oracle is our persistence solution for every application." Or an organization that says, "Use only patterns to solve problems."

  
  For the organization that only uses Oracle, it becomes overkill. The smallest application, with one or two users, doesn't automatically require an Oracle database - serialization, file system, or a smaller database can be totally adequate for that application. When an organization is implementing their active directory, what database would work better with the Microsoft Active Directory products...SQL Server, or Oracle? We all know the answer - Microsoft will gear its products to run best on SQL Server.

  
  So any organization or individual that limits themselves to only one perscribed solution to every problem limits themselves. There will be plenty of times a pattern will be the best solution. There will be times when a pattern will not be the best solution.

  
  Bruce Lee knew this, and it's the reason Bruce Lee stopped his style of martial arts. People thought that Bruce Lee's style was the solution for every fight, and this terribly frustrated Bruce Lee. All the while during teaching, Bruce Lee insisted that the best style of fighting was to "have no style" so one can adapt to any fight with the best moves - not always try to use the same solution that doesn't always fit for problems.
  

  Posted by: phlogistic on September 12, 2005 at 07:52 PM

• "The only thing as dangerous as saying 'do not use patterns' is saying 'you must always use patterns'. "

  Apparently you didn't understand Andreas at all. He doesn't say to not use any patterns, he say you shouldn't stare blindly at them and use them just because they're there.
  People who've been in the trenches writing code for a decade rather than sitting in their ivory tower drawing UML diagrams without ever seeing a line of code have a pretty good idea of what works in their code and what doesn't. They use what the ivory tower architects refer to as patterns instinctively, often not knowing the name that architect calls it and not caring about that name if they do know it.
  When reading some pattern books last year I was quite surprised I'd been using a lot of what's in there instinctively for years, yet when trying to force myself to use those patterns I couldn't. When you reach a level of practical pragmatic experience code flows naturally into what the academics refer to as patterns without conscious effort. But forcing people to use patterns without thought about them except "it's a pattern so it's good" stifles that process, ending up with creating a programmer who lacks any creativity.

  Posted by: jwenting on September 12, 2005 at 11:14 PM

This work is licensed under a Creative Commons License.