Page 1 of 1

Patterns driven design?

Posted: Sun Aug 14, 2005 10:38 am
by Buddha443556
I've always thought of patterns as simplified solutions to common problems. When I see patterns in my code I don't usually give them a second thought unless I need to describe my code to someone then they're rather handy. I usually start thinking about pattern when I get stuck. A glass of ice tea and a little time with PoEAA and well hopefully a solution is found. Hopefully. That pretty much describes my use of patterns.

What I've been noticing at Sitepoint and in the open source community is that patterns seem to be driving design. Take MVC everyone seem to want to implement it. They got a solution, all they need is a problem. This is not exactly the usual development process where you usually start with a problem and try to find a solution. Not that a pattern provides a complete solutions anyway. They're only half baked so some thought is needed.
From PoEAA:

I like to say that patterns are "half baked," meaning that you always have to finish them off in the oven of your own project.
Now I'm not saying this is a terrible thing happening here if indeed it is happening at all. Any thing that gets a programmer to put a little thought into design isn't a bad thing IMHO. In a way, I think software development maybe coming full circle. Design was rather out of vogue for a while in this age of extreme and agile programming and here it is sneaking to the forefront again with patterns.

So what are your thoughts on the matter?

Posted: Sun Aug 14, 2005 10:52 am
by nielsene
I think it depends a lot of a person's level of experience with programming in general and patterns in paticular.

A person who is inexperienced with both programming and patterns probably won't see the point of using patterns nor the intutitive grasping of how to use them.

A person who is an experienced programming, but not really experienced with pattersn will probably do exactly what you're describing as seeing at SitePoint and other places (and its probably what I do). If patterns don't come naturally then you kinda have to design them in -- I'm trying to internalize PoEAA now, but to do so I feel like I'm doing more BDUF than agile mthods want.

Once you're experienced with programming and in "thinking in patterns" the patters just happen, but aren't desigend in. As you develop and run into difficulties you'll either intutitvely refactor to the pattern or take a time out to review pattern catalogs.

I think its just a logical progression.

Also most on-line tutorials/discussion groups/forums can't show the evolvution of code in action (such as the extremely small incremental TDD steps). So they may be posting after the fact and are "retrofitting" the named patterns into theirr implementation to help ask their question/make their point.

Posted: Sun Aug 14, 2005 2:12 pm
by Buddha443556
nielsene wrote:Also most on-line tutorials/discussion groups/forums can't show the evolvution of code in action (such as the extremely small incremental TDD steps). So they may be posting after the fact and are "retrofitting" the named patterns into theirr implementation to help ask their question/make their point.
True, it's just an observation and I could be way off base. I'm just wondering how far?
A person who is an experienced programming, but not really experienced with pattersn will probably do exactly what you're describing as seeing at SitePoint and other places (and its probably what I do).
I'm not sure you can actually be both an experience programmer and inexperienced with pattern? You may not be able to name the pattern you use but that doesn't stop you from using them anyway.
If patterns don't come naturally then you kinda have to design them in -- I'm trying to internalize PoEAA now, but to do so I feel like I'm doing more BDUF than agile mthods want.
I think the inexperienced programmers may also get caught up in this too or at least the one trying to improve their skills.
From PoEAA:

A key part of patterns is that they're rooted in practice. You find patterns by looking at what people do, observing things that work, and then looking for the "core of the solution." It isn't an easy process, but once you've found some good patterns they become a valuable thing.
That how I learned patterns. The hard way via actual practice. Obviously there are other ways to learn these days. Maybe even a better way.

Re: Patterns driven design?

Posted: Sun Aug 14, 2005 3:29 pm
by McGruff
Buddha443556 wrote:What I've been noticing at Sitepoint and in the open source community is that patterns seem to be driving design. Design was rather out of vogue for a while in this age of extreme and agile programming and here it is sneaking to the forefront again with patterns.
I'm not sure which thread/s you're referring to but I can think of one major design effort which isn't necessarily exemplary code, at least in my opinion.

Requirements rather than patterns should drive design; patterns should just pop into your head when faced with a coding problem. If you study all the pattern resources you can find they'll eventually get absorbed into your unconscious coding brain.

Xp encourages you to focus strictly on the requirements - but what are the requirements...?. The lesson here seemed to be that programmers should be prepared to make intelligent additions to client requirements if required - and that might mean looking ahead. Once these are properly stated, then it's XP just-enough-code as normal. At least that's how I intrepreted it.

I think you might have been referring to a thread where the mandate is to design an MVC framework. Is that a good requirement? It's certainly not as tightly focussed as a client provision such as "show a list of all creditors more than three months overdue". It's hard to code to requirements which are as vague as this.

Perhaps creating a framework is the most difficult thing of all. Ideally it should be slim; it shouldn't do anythig you don't always need to do. On the other hand it must be sufficiently powerful to cope with whatever type of problem you might need to solve. These two pressures are pulling in different directions and perhaps there is no perfect way to resolve them. Perhaps the art of a framework author is to make best guesses and intelligent compromises in order to create something which will work well for the most common cases or in a chosen domain.

MVC itself isn't that important - and probably gets first prize as the most misunderstood design pattern around (is Ruby rails really MVC for example?). The really important thing is to separate presentation and domain whether or not you also split presentation into controller and view a la MVC.

Re: Patterns driven design?

Posted: Mon Aug 15, 2005 10:43 am
by Buddha443556
McGruff wrote:I'm not sure which thread/s you're referring to but I can think of one major design effort which isn't necessarily exemplary code, at least in my opinion.

....

I think you might have been referring to a thread where the mandate is to design an MVC framework. Is that a good requirement?
Actually it was just a very broad intuitive observation. What I'm probably seeing is the influence of programmers like Nielsene who are busy development software and learning patterns at the same time.

I find it interest the that we represent three different ways of learning patterns here: Me and my practice approach, McGruff and his read the book approach and Nielsene and his hybrid read it - apply it approach. Looks like a natural progression. Maybe we represent three different generation of programmers?

Posted: Mon Aug 15, 2005 10:59 am
by nielsene
Buddha443556 wrote:
A person who is an experienced programming, but not really experienced with pattersn will probably do exactly what you're describing as seeing at SitePoint and other places (and its probably what I do).
I'm not sure you can actually be both an experience programmer and inexperienced with pattern? You may not be able to name the pattern you use but that doesn't stop you from using them anyway.
I know many experienced programmers who wouldn't know a "pattern" if it bit them on the ...
I work with a lot of old-school C programmers, absolute geniuses at optimizing complex matrix operations, etc. None of them are fluent in OOP. While there are "procedural patterns" theres no real "pattern catalogue", their "design vocabulary" is maining Data Structures and Algorithms (a mix of CLR and TAOCP). While I "know" OOP, I've worked in this environment more... 15 years or so of heavily procecedural code/simulation/AI -- so I feel I'm a rather experienced programmer, with a mainly theoretical understanding of OOP. While I've done a few small projects with OOP, I haven't done anything too large. I see the benefits and I want to adopt it... I'm playing with the patterns primarily to help understand the way a large OOP application will look, so yes I'm doing a lot of "what-if" design with patterns to try to see how it all fits together. In practice stuff still grows incrementally via TDD for me.

Posted: Mon Aug 15, 2005 12:10 pm
by Buddha443556
nielsene wrote:I see the benefits and I want to adopt it... I'm playing with the patterns primarily to help understand the way a large OOP application will look, so yes I'm doing a lot of "what-if" design with patterns to try to see how it all fits together.
Probably the way I would have done it if PoEAA had been published 30 years ago.
I know many experienced programmers who wouldn't know a "pattern" if it bit them on the ...
I work with a lot of old-school C programmers, absolute geniuses at optimizing complex matrix operations, etc. None of them are fluent in OOP. While there are "procedural patterns" theres no real "pattern catalogue", their "design vocabulary" is maining Data Structures and Algorithms (a mix of CLR and TAOCP).
I'm still sure your old-school C programmers use patterns finding them is the hard part.

:oops: I've got "Algorithms + Data Structure = Programs" right next to PoEAA hope that doesn't offend McGruff.
... rather experienced programmer ...
I have absolutely no doubt you are an experienced programmer. Hope you don't think I implied otherwise.

Posted: Mon Aug 15, 2005 12:20 pm
by nielsene
... rather experienced programmer ...
I have absolutely no doubt you are an experienced programmer. Hope you don't think I implied otherwise.
No didn't think you were, but I just trying to make the point that experience programmers != experienced OOPers. You kinda made that point in your first response to me about not being sure someone could be "an experienced programmer and inexperienced with patterns".

I don't know many non-OOPers who speak in Patterns, even if they do have "common solution templates" for certain types of tasks. And of course almost all the Agile Methods are centered around OOP, so some of the "old-timers" who have stuck with non-OOP languages don't have any experience with this, but are still highly experienced programmers, etc.

Kinda a "Patterns" versus "patterns" -- only OOP/agile methods really focus on "capital P" Patterns. Other people just consider it "good ways of solving a problem I've seen before". OOP does help to reduce the pattern to its bare essentials in a way that helps highlight the pattern versus the implementation. Its fairly trivial to adapt a Java Pattern to PHP for instance. However taking some of the "patterns" I'm used to in a non OOP sense are often coupled much more tightly to the implementation language and data structures and thus are harder to use in the more general sense.

Posted: Mon Aug 15, 2005 1:51 pm
by Buddha443556
nielsene wrote:... experience programmers != experienced OOPers ...
Agreed.
nielsene wrote:Kinda a "Patterns" versus "patterns" -- only OOP/agile methods really focus on "capital P" Patterns. Other people just consider it "good ways of solving a problem I've seen before". OOP does help to reduce the pattern to its bare essentials in a way that helps highlight the pattern versus the implementation. Its fairly trivial to adapt a Java Pattern to PHP for instance. However taking some of the "patterns" I'm used to in a non OOP sense are often coupled much more tightly to the implementation language and data structures and thus are harder to use in the more general sense.
Some OOP programmers definitely spell "Pattern" with a capital "P". I will disagree that it's a "Java" Pattern. If you can adept a Java pattern to PHP does that make it now a PHP pattern? The language is irrelavent in my opinion (unless of course you don't understand the languages involved which brings our old school C programmers to mind). It's just difficult to go from OO language to a non-OO language, patterns or not, the opposite isn't easy either.

Posted: Mon Aug 15, 2005 2:12 pm
by nielsene
Buddha443556 wrote:
nielsene wrote:Kinda a "Patterns" versus "patterns" -- only OOP/agile methods really focus on "capital P" Patterns. Other people just consider it "good ways of solving a problem I've seen before". OOP does help to reduce the pattern to its bare essentials in a way that helps highlight the pattern versus the implementation. Its fairly trivial to adapt a Java Pattern to PHP for instance. However taking some of the "patterns" I'm used to in a non OOP sense are often coupled much more tightly to the implementation language and data structures and thus are harder to use in the more general sense.
Some OOP programmers definitely spell "Pattern" with a capital "P". I will disagree that it's a "Java" Pattern. If you can adept a Java pattern to PHP does that make it now a PHP pattern? The language is irrelavent in my opinion (unless of course you don't understand the languages involved which brings our old school C programmers to mind). It's just difficult to go from OO language to a non-OO language, patterns or not, the opposite isn't easy either.
Sorry, I must have been unclear. But I think we're in agreement. By saying "its fairly trivial to adapt a Java Pattern to PHP" I meant exactly what you said. Language is (generally) not relevant in Pattern discussion, so it doesn't matter that 99% of the examples are in Java.

Posted: Mon Aug 15, 2005 2:44 pm
by Buddha443556
nielsene wrote:Sorry, I must have been unclear. But I think we're in agreement. By saying "its fairly trivial to adapt a Java Pattern to PHP" I meant exactly what you said. Language is (generally) not relevant in Pattern discussion, so it doesn't matter that 99% of the examples are in Java.
Yep we agree.