Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Are design patterns worth it?

by FoxtrotUniform (Prior)
on Aug 28, 2002 at 02:22 UTC ( [id://193340]=perlquestion: print w/replies, xml ) Need Help??

FoxtrotUniform has asked for the wisdom of the Perl Monks concerning the following question:


In a moment of honest self-reflection, I realized that most of the software I've worked on over my past year and a half of employment fits the Big Ball of Mud pattern. Much of my code started off as either a throwaway or a prototype, which I never quite had the time to rewrite later. Some of it (the minority, I think) is a maintenance minefield.

That said, some of it's fairly good, well-documented, loosely coupled, easy to maintain code.

Should I be concerned that my code doesn't fit the Gang of Four's vision of architectural sophistication? Are design patterns all they're reported to be, or even close? None of these programs are is longer than two thousand lines: relatively small potatoes compared to some of the systems we use. Is their scale too small for pattern-based design to make an appreciable difference?

Am I admitting that I have a problem, or just being paranoid? What experiences have you had?

F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

Replies are listed 'Best First'.
(jeffa) Re: Are design patterns worth it?
by jeffa (Bishop) on Aug 28, 2002 at 03:06 UTC
    I studied C++ and the GoF book long before i embarked upon the Perl path. At some point during my journey down the Perl path, i thought it would be really neat if someone (me) wrote Perl versions of each of the GoF Patterns. Well, someone already did (partially) - But, there is a funny thing about Perl - read Dominus's "Design Patterns" Aren't for more.

    I personally think that Design Patterns are worthy of studying, they can really help you design better. There are real world examples of Design Patterns implemented in Perl, such as what Matts discusses at his paper on Proxy Objects. There are plenty of other examples here at this site, such as a Factory Pattern that i demonstrated a while back (be sure and read Kanji's and merlyn's comments from the root thread as well if you do follow that link). Just try the new and improved Super Search (tye++ once again).

    Now, are Design Patterns going to reverse the Big Ball of Mud for you. No, only you, your co-workers, a lot of planning, and time can do that, but that doesn't mean that you shouldn't learn how a few patterns work. You never know when they might be useful. I wish you the best of luck, i myself have been handed a medium sized ball of mud (written in ASP and VBA for Access, no less) that someone else wrote. Right now, the most critical piece to shaping this lump into a more manageable product is to clean up the database schema - to bad the GoF didn't invent a Preventative LART Pattern*. I can't complain though, it is nice to be employed again. :)


    * prevents non-coders from thinking they can
Re: Are design patterns worth it?
by dws (Chancellor) on Aug 28, 2002 at 02:55 UTC
    Should I be concerned that my code doesn't fit the Gang of Four's vision of architectural sophistication?

    Not necessarily.

    Are design patterns all they're reported to be, or even close?

    Yes, with caveats. (See Design Patterns Considered Harmful.)

    Design patterns capture solutions to specific types of problems. The Gang of Four patterns are fairly generic. Additional, domain-specific patterns are also plentiful (witness the multi-volume Pattern Languages of Programming (PLOP) series.) The generic patterns are a good thing to know, because they do affect the way you look at design, in the same way that having a big bag of programming tricks can help you implement. Many of the GoF patterns are really not that sophisticated, but they do depend on structuring your code into classes. Depending on what you're doing, that might be overkill.

    Is their scale [< 2000 lines] too small for pattern-based design to make an appreciable difference?

    Not at all, though it depends on whether you have a problem that a pattern helps you solve. I regularly use the "Strategy" pattern on medium sized (~1000 line) scripts, but that's because a couple of things I like to do are natural candidates for strategies.

      Consider Design patterns as models whose basic structures can be altered to meet your design needs. I studied C++ Design Patterns some time ago- quite a bit before beginning to learn Perl. What I gained from them were concepts of how to conceptualy break large projects into modules whose basic concepts and purpose can be communicated in a manner that is easily understood by others. I have often found that although I come nowhere near meeting the design standards I dream of - that just the process of involving my peers in some discussion of patterns concepts stimulates our thinking use some of these concepts. Don't be so hard on yourself and remember "Cape does not enable user to fly". Spidey
Re: (nrd) Are design patterns worth it?
by newrisedesigns (Curate) on Aug 28, 2002 at 03:20 UTC

    I wrote a CGI application that was to be incredibly simple, just a portal for user-defined links. This program, while being written, experienced many design/function changes from above. I had to patch code together to get it done quickly (the client didn't know that changes = time); in the end, it's become an ungodly mess. It usually takes me five minutes to find a problem, and 30 seconds to fix it. I dread doing an update for my code has become "write-only."

    I'm writing some new code in my leisure time. I could have written without and source formatting or comments, but I know from my previous experience that updating badly formed code takes all the fun out of programming. I've had many side projects die because in my hasty attempt to complete my idea before it left the station without me aboard, I left no clues for me to pick up where I had left off. This recent "fun" project is taking longer than expected, but it's worth it.

    I think that given certain outside variables (your %ENV :), one should choose between the quick-and-dirty or the refined, elegant method. Both have some advantages and disadvantages (namely time and revision-ease). To use a driving metaphor, it's always a pleasure to take the scenic route, but sometimes you need to get there on time. A healthy mix of both seems the best way to go, if possible.

    John J Reiser

Re: Are design patterns worth it?
by diakonos (Hermit) on Aug 28, 2002 at 13:19 UTC
    Design patterns can be a good thing. Especially when working in a fast paced project group. Many times (Shall I say most all the time) the code you create today is the same code someone else changes tomorrow. Without some sort of "known structure" (not intense design patterns) that all have painfully tried to follow it can become difficult. To me the reason for this is quite simple. After everyone in a project group learns a specific "structure" then modifications become quicker and easier.

    That said, I think there is one more area that holds more importance than having a set structure. DOCUMENT, DOCUMENT, DOCUMENT. (Have you ever tried to quickly figure out a two line regex? - "Man those comments are nice")

    You will see a lot of different code in your lifetime. I believe that a person's code is similar to their fingerprint. In project groups now and in the past I can always tell who wrote the code without looking at their signature on the header comment lines.

    Don't sweat it if your code doesn't "look like the rest". But if you use design patterns don't let it destroy your code (making it more complicated than it should be). I don't scream when I run into the "BIG BALL OF MUD". Actually much of mine has been named as such.

    Have a great day!

Re: Are design patterns worth it?
by gregor42 (Parson) on Aug 28, 2002 at 16:19 UTC

    IMHO - Fundamentally Design Patterns are a Good Thing.

    That being said - you need to understand the underlying philosophy that drove the creation of them in the first place.

    There's not one person who's ever taken up programming that hasn't created a BALL OF MUD. The idea of design and software architecture in general is to make our lives easier.

    That paper is a classic that's been quoted time & time again here. It explains the tribulations of attempting to use the design pattern philosophy in the real World.

    My answer to you - if you want to call it that - is that you need to stop thinking of Design Patterns as a thing and absorb rather the essence of the underlying widom.

    As you grow and learn as a software developer something interesting happens. You might in some ways say that you become less productive - in that you meditate over your code more before rendering it, and therefore write less code. But on the other hand, the code you write should be easier to maintain in the future. Futhermore, it should be less likely to be in need of being rewritten. It should incorporate all that you have learned from your experience & mistakes about how to save yourself a lot of work later by planning slightly more up front. It should reflect lofty goals like code reuse and component-ization.

    But very much like Architecture in construction - the lay of the land dictates a lot.

    I have embraced the concept of Open Standards wholeheartedly & as such became both a perl and a Java programmer. What I have noticed is that the languages themselves tend to drive you to think in certain ways. perl is a lot easier to hack in. If you want to you can usually create some THROWAWAY CODE in very few lines to get something working.

    Java, in many ways, lends itself more to Architecture since it's not so easy to just create that "one-off proggy". It requires more effort, and as such, it sort of forces you to think before you code.

    The upshot of this is that here at my job, I do my rapid prototyping in perl. But perl code for production use is frowned upon in this company due to maintainability issues. (We're not very replete with perl coders.)

    So - to follow the process outlined in the article - I prototype for FUNCTION. Then I step back, look at what I've learned about the problem domain from the prototype, incorporate it into the design and then THROW THE CODE AWAY.

    The next iteration produces a Java based project, along with corresponding UML and documentation.

    Now I've noted that since we have a language boundary - it forces code to be discarded. That's a rather unique scenario however. Most companies don't operate this way. Also - I am a Maverick in that I insist on doing things the "right" way and openly and repeatedly attack my managers for attempting to make costly mistakes by 'cutting corners.' The simple fact that I take the time to write a prototype in perl at all goes directly against the grain of the culture here.

    But then, as I've been quoted of saying in the past: Never Under Estimate the Power of What Works.

    Note however, that taking that quote too literally can also lead to BIG BALLS OF MUD. As in when it is misinterpreted as "If it ain't broke, don't fix it."

    Caveat Emptor!

    Wait! This isn't a Parachute, this is a Backpack!

    20060928 Update: Replaces heretical usage of 'PERL' with 'perl'.

Re: Are design patterns worth it?
by jmcnamara (Monsignor) on Aug 28, 2002 at 07:22 UTC

    Are design patterns all they're reported to be, or even close?

    I came across this recently on Dominus's site: "Design Patterns" Aren't

    It was one of his Lightning Talks at YAPC::NA 2002.


Norvig article
by hding (Chaplain) on Aug 28, 2002 at 11:54 UTC
Re: Are design patterns worth it?
by Corion (Patriarch) on Aug 28, 2002 at 16:45 UTC

    Personally, I really like Design Patterns, but you always have to take them with a grain of salt, much more like a metaphor or legend than a design specification, describing in an abstract way, how a certain class of problems has been approached and what the consequences of that approach were. They also allow me to communicate easier with other people, as a Design Pattern creates a common name for something that would have to be described otherwise.

    When looking at Design Patterns, you must decide, if you are the intended audience. The GoF book focuses on a C++ audience - Perl already has other idioms that deal with many of the patterns, for example the Iterator pattern, which is simply foreach, so not all patterns you find in the GoF book are directly useful for a Perl programmer (and in fact, not many are useful with a dynamic language).

    But patterns are also available for user interface design and other stuff, and these patterns can be helpful, if you want to provide a feature, but don't know yet, how it could be presented to the user.

    perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
Re: Are design patterns worth it?
by stephen (Priest) on Aug 28, 2002 at 17:37 UTC

    I don't think you have a problem-- or if you do, you also have the solution. You recognize the difference between "maintenance minefield" and "good, well-documented, loosely coupled, easy to maintain code." Once you've got that distinction, you can refactor the minefields into grassy plains as you need.

    Design patterns do not define good design. They merely specify one way of getting there, and serve as examples of it. If the code is expandable, documented, and orthogonal, I don't care if it's DP-based or not.

    My usual method of dealing with partially muddy designs is as follows:

    • If the code works and doesn't need to change, I don't mess with it. I write automated unit tests for it as a background task, just in case I ever do need to fix it.
    • If I need to make a change, I start by checking my unit tests to make sure they test things out well. Then I refactor bit by bit.
    • If the code doesn't work, then I'll rewrite it-- or at least the broken portions.

    The only worry about bad-but-working code is the fact that bad code begets bad code. If I'm working on a project that uses a lot of globals, it's always tempting to add more globals in my new code... after all, why not? There are globals there already. It's a quick downward slide to coding cynicism.

    My interactions with a Big Ball of Mud are detailed in Failure To Refactor.


Re: Are design patterns worth it?
by beamsack (Scribe) on Aug 29, 2002 at 21:48 UTC
    The first chapter of the GOF book is worth reading for any OO practioners. Especially the discussion on favoring composition over inheritance. Functional programmers have been using composition since day 1. It seems like the OO movement has been trying to work functional programming back in. Design Patterns is a perfect example. Many of the patterns involve classes with only methods (such as the Strategy pattern). This goes against basic OO which defines a class as encapsulated data and the methods that operate on this data. OO teams would be wise to investigate GOF and some newer literature on OO to expand the teams vision beyond the limited capabilities of Novice level OO.
Re: Are design patterns worth it?
by cybear (Monk) on Aug 29, 2002 at 12:15 UTC
    Good question. I have run into that same sloppy but working prototype, "hurry and get to the next project situation".

    I think that the benefits of following a standard, with an easy to follow and repeatable
    pattern outweights the additional time it takes to get the formatting ready.

    Especially if you think that you'll be shoved on to the next project as soon as you get this
    one working. I try to use templates myself, that was all that you have to do is fill in the
    blanks. :-)

    - cybear

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://193340]
Approved by rattusillegitimus
Front-paged by newrisedesigns
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (4)
As of 2024-07-15 05:43 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.