12 Replies Latest reply: Oct 20, 2010 2:28 PM by 796367 RSS

    How to get start with design patterns?

    579510
      Hello All,

      I am a Java programmer and recently started looking at what design patters are. I started with Gang of Four and kept it aside after reading around 30 pages as felt very high level and then took Head First Design Patterns and stopped reading it after looking at initial chapters. This is because though I was able to follow from the implementation but could not really think in the real time usage this could be because I was never into designing.

      Did I pick up the good books or should I pick up any other one? Some one please help me.

      Thanks,
      Kiran

      Edited by: Kiran M on Oct 2, 2010 8:11 PM
        • 1. Re: How to get start with design patterns?
          jduprez
          I'm not sure either book is guilty.
          The first time I read the GoF's book, I was immediately hooked and turned on - and believe me, the French translation is the densest litteracy I've ever read!
          Probably because half of the book treated problems I had already met, presented solutions I had never thought of, or that I had approached but not analyzed, or that I hadn't theorized,... and most of the other half described problems I had not yet met, but seemed likely to be traversed one day or the other.
          In other words, it probably takes experience (preferrably painful experience) to appreciate this book :o)

          That being said, my own journey to understanding patterns started with Bruce Eckel's "Thinking in Java" chapter dedicated to them. Although the book is widely criticized, this chapter justified to dig the notion further. I then went to discover the C2 Wiki (nowadays probably a bit to rich to be leveraged by a beginner), which convinced me further that I needed to buy and erad the GoF's bible.

          Then I started hanging around (mostly reading), on the "OO Design and pattern" forums. So, you're probably on right tracks already. Keep digging, and much luck.

          Jérôme
          • 2. Re: How to get start with design patterns?
            jschellSomeoneStoleMyAlias
            ...in the real time usage this could be because I was never into designing
            What does that mean?

            That you don't design?
            On that you work in real time java and do not think that the patterns apply?

            Patterns are supposed to originate with experience.
            • 3. Re: How to get start with design patterns?
              579510
              Thanks Jerome.
              • 4. Re: How to get start with design patterns?
                800459
                I am a Java programmer and recently started looking at what design patters are.
                That's good.
                Head First Design Patterns and stopped reading it after looking at initial chapters.
                I am reading the same book and find it very good. it simplifies the concept to greater extent.
                but could not really think in the real time usage this could be because I was never into designing.
                Start looking into java API for usage of patterns, that will give you some idea. Here are few examples
                XML Api to work with XML : Uses factory patten to give you DOM Builder
                Java Servlet :Generic Servlet ->HttpServlet, uses Template pattern
                Collections.sort(list, comparator) , uses Strategy pattern..

                You can find lot more..I hope this will motivate you to start reading it again.
                • 5. Re: How to get start with design patterns?
                  800928
                  I meet the same problems.

                  When I read the exmaples in the book, I just found that the pattern is rather good,but I can not tell the real advantages ,so I do not understand the pattern actually.
                  Maybe just like ' jduprez' said we need (preferrably painful experience) to appreciate the book.
                  That's to say, experienece is so importment,one can not appreciate the pattern until he experience enough? Is that mean one have to go through this period?

                  If so , I would be lose my heart more or less.

                  BTW, when I read the book, I found I can not understand some professional words such as Loosely coupled and etc, I am not exactly sure I got it or not.
                  So in my opinion ,all of this is caused by my poor knowledge about the "OO(Object-Oriented)" itself,I ask myself if I really know clearly about the Inheritance peptides?Answer is no.
                  So, I want to ask you guys is there any ways to get more knowledge about the OO? I believe that all the Patterns are built based on the OO itself.

                  During my work,after I implement the requried functions, I would refactor the codes more than one time,but the effect is little.

                  Guys, please.
                  • 6. Re: How to get start with design patterns?
                    796367
                    apachemaven wrote:
                    ... Maybe just like ' jduprez' said we need (preferrably painful experience) to appreciate the book. That's to say, experienece is so importment,one can not appreciate the pattern until he experience enough? Is that mean one have to go through this period?
                    I think so. However, there are things that you can do to ease the learning curve. Start out simple -- which may not be so simple, because trying to figure that out is difficult at best.

                    As far as patterns are concerned, it is far better to be able to write a simple, solid, and robust JAVA class BEFORE you try learning patterns. Patterns evolved long AFTER people were making good class definitions. A good analogy may be a musician knowing the scales BEFORE composing a symphony. The same applies to this topic too, a good JAVA class is like knowing the scales, and patterns is like the entire symphony.

                    One last thing... patterns will only come easy IF the rest of your code is correctly defined and executed. In other words, if your coding practice is weak in any area, that in itself will throw off the effectiveness of the pattern you are trying to use.
                    • 7. Re: How to get start with design patterns?
                      800928
                      In other words, if your coding practice is weak in any area, that in itself will throw off the effectiveness of the pattern you are trying to use.
                      So, I think the basic understanding of the OO is rather importment,but for myself it seems that I do not know where is my weakness. That's to say, I can not know clearly about the ability of myself.

                      I always wish if there is a test after which it can figure out me that where is my weakness, and then give me a guide to improve. I know this is rather Whimsical. :)
                      • 8. Re: How to get start with design patterns?
                        796367
                        apachemaven wrote:
                        ... I always wish if there is a test after which it can figure out me that where is my weakness, and then give me a guide to improve. I know this is rather Whimsical. :)
                        Maybe, but you are on the right track!

                        First, I think it greatly depends on the fact if you are typeing your code into an IDE, or typing in by hand in a plain old text editor. I always use a plain old text editor -- Notepad... because it forces me to type in every cotton-pickin' line of code.

                        Second, is the code I writing can be done with fewer lines. That is, are there any redundencies that should be encapsulated into methods... IF so, what class should those methods be in? Should those methods be <tt>static</tt> or class members? AND what should the access specifier be -- <tt>public, protected, private</tt>?

                        Third, the <tt>javac</tt> will tell you that something is not right with the code.

                        etc..
                        etc..

                        If you've gotten this far, your skills are improving, but there will always be more bumps in the road... especially when you start sailing into uncharted territories. The best thing I can tell you, is get away from IDE's untill you have your bearings broke in. I still refuse to use IDE's because I can type almost as fast as they can, and if you are going to maintain the code you write, it is better to know every single line intimately.
                        • 9. Re: How to get start with design patterns?
                          jduprez
                          When I read the exmaples in the book, I just found that the pattern is rather good,but I can not tell the real advantages ,so I do not understand the pattern actually.
                          Maybe just like ' jduprez' said we need (preferrably painful experience) to appreciate the book.
                          That's to say, experienece is so importment,one can not appreciate the pattern until he experience enough? Is that mean one have to go through this period?
                          ... Maybe just like ' jduprez' said we need (preferrably painful experience) to appreciate the book. That's to say, experienece is so importment,one can not appreciate the pattern until he experience enough? Is that mean one have to go through this period?
                          I'm sorry if that sounds harsh and haughty. But I still think it's key (except the "painful" bit, which is merely rethorics).
                          Design Patterns describe well-known solutions to recurring problems. In OOD (indeed, OO Design Patterns are not the only patterns, nor even the only design patterns, there are a lot more domain for which patterns have been discovered and documented), OO Design Patterns mostly cover how to add flexibility to your design in order to cope with change.

                          The highlighted words above are appreciated with experience. Even if modern CS courses taught how much change is a constant in our industry (and frankly, I doubt that they do), it would still be difficult for the beginning programmer to evaluate, upfront, how much, where, when, why, change will be required. I think it takes a few years of actually developing an application that is actually used and actually maintained, to realize how much change is necessary, which forms do changes take, which kind of design constructs they impact.
                          I don't think a student context (much less a hobby-at-home context) cover these three "actually" enough to teach you how to properly introduce flexibility.

                          Of course there are some teachers/courses/internships that will teach you the necessity of flexibility.
                          Down-to-earth students may miss the point (I have met some interns, and even some profesionnals, which have failed to bring themselves to actually accept change)
                          Smarter ones will understand, but they will often fall prey to an extreme interpretation: +"hey let's add flexibility, indirection, configurability, dynamicity, everywhere"+. In OOD world and especially on this forum, we happen to mock that as the "small boy with a pattern" syndrome.
                          Putting flexibility everywhere has costs, initial development is heavier and more expensive, validation is broader more expensive, design and code intent is blurred, maintenance is harder and more expensive.

                          In summary, you have to set the cursor right, between monolithic and frozen design, and fancy and overly complex design
                          I think so. However, there are things that you can do to ease the learning curve. Start out simple -- which may not be so simple, because trying to figure that out is difficult at best.
                          Yes. In particular it's probably preferrable to understand OO concepts and vocabulary before embarking the patterns boat, as evidenced by:
                          BTW, when I read the book, I found I can not understand some professional words such as Loosely coupled and etc, I am not exactly sure I got it or not.
                          These words are no more professional than "class", "design", or "home run" (although that latter may be more applicable to other professions).
                          But they are a necessary tool for the field, yes, be it in a professional or less formal context.
                          So in my opinion ,all of this is caused by my poor knowledge about the "OO(Object-Oriented)" itself,I ask myself if I really know clearly about the Inheritance peptides?Answer is no.
                          So, I want to ask you guys is there any ways to get more knowledge about the OO?
                          I can shovel my learning path, but I don't know if it applies unchanged to someone I don't know. Pick your battles:
                          - I learnt OO formally with Ada. I deem I was fortunate to apply this OO knowledge to Java soon after (because Ada's syntax doesn't makes its OOness very apparent), so I deem I learnt OO on the field using Java.
                          - I was fortunate enough to meet maintenance problems soon enough that I had to have a look at various OO resources. I can mention Robert C. Martin's article on the Open-Closed Principle, Dependency Inversion Principle, Abstraction Dependency Principle.
                          - I discovered Design Patterns while reading a chapter of Brice Eckel's book "Thinking in Java", which is often criticized but gave me enough of an incentive to go on the Web and devour a lot of patterns-based litterature, until I eventually bought the GoF book.
                          - From that point on, I felt I had to strengthen some fundamentals, which I found in Bertrand Meyer's "Object-Oriented Software Construction", on the C2 Wiki, and in Martin Fowler's "Refactoring" book.
                          - Eventually, althoguh I found most advices in books and articles, the weight and confidence I put in that advices, and the selectivity with which I apply them, stems from actually working with Java and a pair of other languages, frameworks such as Spring, EJb, the JDK API and several third-party libraries etc,... Which I summarize as "experience".

                          As you can see I read most of the resources after the fact, with a learning path aided by experience, so they may not be the "learn the basis" books you need (the weight alone of Meyer's book in particular, is enough of a deterrent to a beginner OO Designer). Pick what you deem useful.
                          During my work,after I implement the requried functions, I would refactor the codes more than one time,but the effect is little.
                          Technically speaking, "refactoring" the code is supposed to have no effect on the functionality, and small to substantial effect on the maintainability of the code that supports it.

                          But that gives me an occasion to point out one the sources I mentioned above: I find the "motivation" sections of Martin Fowler 's book *"Refactoring"* one of the best design aid I've ever read. I suggest you definitely have a look at this book (in a much easily readable style than the GoF bible, and by definition full of small code examples, so definitely accessible to a beginner). It will hopefully teach you some of the basis, and also equip you with a very useful tool, namely, refactorings (built-in in most IDEs nowadays, but the strictness of their "manual" implementation is quite self-teaching).

                          Much luck,

                          Jérôme
                          • 10. Re: How to get start with design patterns?
                            jduprez
                            Hello Pierrot. I like the theme of your analogy, but I find it misleading in the details.
                            A good analogy may be a musician knowing the scales BEFORE composing a symphony. The same applies to this topic too, a good JAVA class is like knowing the scales, and patterns is like the entire symphony.
                            As a (would-be, mediocre, and hopeless) musician, I'd merely phrase that as:
                            Java is your instrument, the basic OO principles are the scales, patterns are the melodic and harmonic theories that analyze and document how notes, scales, and chords are organized in small sequences and bundles, and the application is the symphony
                            Oh and the application spec is the composer's intent, who for example wanted to evoke a river of central Europe without any word sung.

                            Sorry if you find this nit-picking, but I wanted to stress that patterns are not an end in themselves.
                            One last thing... patterns will only come easy IF the rest of your code is correctly defined and executed. In other words, if your coding practice is weak in any area, that in itself will throw off the effectiveness of the pattern you are trying to use.
                            I don't understand this part. Do you have an example in mind?
                            • 11. Re: How to get start with design patterns?
                              jschellSomeoneStoleMyAlias
                              jduprez wrote:
                              One last thing... patterns will only come easy IF the rest of your code is correctly defined and executed. In other words, if your coding practice is weak in any area, that in itself will throw off the effectiveness of the pattern you are trying to use.
                              I don't understand this part. Do you have an example in mind?
                              I can think of an example - if the developer overuses inheritence and doesn't understand why composition should be preferred. How would then one correctly use the Proxy Pattern? That of course would be only one pattern that would be severly impacted by such a misuse.
                              • 12. Re: How to get start with design patterns?
                                796367
                                jduprez wrote:
                                Hello Pierrot. I like the theme of your analogy, but I find it misleading in the details.
                                pierrot_2 wrote:
                                A good analogy may be a musician knowing the scales BEFORE composing a symphony. The same applies to this topic too, a good JAVA class is like knowing the scales, and patterns is like the entire symphony.
                                As a (would-be, mediocre, and hopeless) musician, I'd merely phrase that as:
                                Java is your instrument, the basic OO principles are the scales, patterns are the melodic and harmonic theories that analyze and document how notes, scales, and chords are organized in small sequences and bundles, and the application is the symphony
                                Oh and the application spec is the composer's intent, who for example wanted to evoke a river of central Europe without any word sung.
                                Sorry if you find this nit-picking, but I wanted to stress that patterns are not an end in themselves.
                                jduprez, and I must say... I like the way you put it better.
                                One last thing... patterns will only come easy IF the rest of your code is correctly defined and executed. In other words, if your coding practice is weak in any area, that in itself will throw off the effectiveness of the pattern you are trying to use.
                                I don't understand this part. Do you have an example in mind?
                                Yes, this actually occurs more for programmers who have not really learned to encapsulate data and methods into solid, individual class files at the outset. For the benefit of simplicity I'll lay down a few rules.
                                - An APPLICATION is responsible for handling each class object properly. That is, the Application must respect the wishes of the objects contained therein. The Application must find a way to pass valid arguments to those classes, and it must provide a way to handle data that it asks in return.
                                - A class should protect its inner details and data by setting the access specifiers accurately on its own class members.

                                Now back to my example. As you know, a pattern itself can span over (encapsulate) several classes or interfaces in its own right. In my opinion, when the pattern is written, it looks like an interface, but when the pattern is running (being executed), it behaves like a tiny inner application (that resides inside the larger application) -- similar to the fact that any class can encapsulate an inner class. With a pattern, I would say that an application can encapsulate smaller inner applications (one being the pattern).

                                Simple applications can get away with just using a handful of classes or less -- and do not need the flexibility that patterns provide. These applications can run as is. However, as a particular application grows in size and complexity, it may require some type of pattern to handle things that classes cannot do (and should not do) on their own. When you see the *.java* source code for these classes, all you see is a class fie that implements an interface. It is very difficult to see the pattern from looking at the code from one class. But when these classes are being executed during runtime, then the behavior manifests itself. It's like there is a tiny inner application running inside the larger app.

                                Now back to the point, and to requote myself...
                                In other words, if your coding practice is weak in any area, that in itself will throw off the effectiveness of the pattern you are trying to use.
                                ... What I mean is;
                                - IF the Application does not repect the wishes of the objects contained therein -- the objects can only do so much on their own;
                                - IF the Application does not pass the correct and valid arguments to those objects;
                                - IF the Application does not handle data correctly that it asks of those objects;
                                - IF the Classes do not encapsulate data and methods correctly and provide proper access specifications;
                                THEN trying to utilize a pattern would not be an improvement... rather, there will just end up beng more code in the way. The end result will be a non-flexible application -- which is the opposite result of what the pattern was trying to do. In other words, patterns are only effective and an asset when all your other objects are capable and can behave on their own. To see this with a real live analogy, think of an All-Star Footbal Team vs a Footbal Team composed entirely of Misfits. Which team is going to know more plays, and be flexible enough to change routines on a play-by-play basis?

                                And the final word:
                                Sorry if you find this nit-picking, but I wanted to stress that patterns are not an end in themselves.
                                That's right, and if one doesn't cover all the bases first, then the application using the pattern will only result in dissonance, and the sound of a central european river will turn into wild accusations of romantic explicatives!