On Wed, Feb 27, 2008 at 5:58 PM, Aschwin Wesselius <aschwin@xxxxxxxxxxxxxx>
wrote:
> Nathan Nobbe wrote:
> > adding layers of abstraction arbitrarily is foolish no matter what style
> the
> > code is written in. design patterns are largely methodologies for
> adding
> > abstraction but it takes time and practice to know when to use a
> particular
> > pattern and how to implement it.
> > one of the things that functions, and patterns do in general is assign
> > labels
> > to concepts. this is where functions take the first step over
> procedural
> > code;
> > you have something people can refer to in an abstract way; w/o referring
> to
> > the implementation. this enhances conversations, and reduces
> complexity,
> > think about a conversation where people are discussing a procedural
> block of
> > code; "you know in said file, where the code does that one thing..."
> where
> > as
> > w/ a function, you can easily refer to the functionality; "you know, the
> > doThatOneThing() function..". patterns do the same thing for software
> > engineering,
> > so rather than saying; "dude, i built this thing where other things can
> like
> > register,
> > then they can like all get messages from it when it changes.." thats
> where
> > a patterns guy steps in and says "ya dude, thats observer!". and if you
> all
> > know about it in advance you can save yourself the hassle and just say
> > observer,
> > then youre all on the same page immediately. think of the impact this
> has
> > on a design session; it doesnt quickly degrade into a low level
> conversation
> > about implementation details, because you already know how to implement
> > observer.
> >
> Thanks, Nathan. I do understand the purpose of patterns and I am willing
> to learn them (or trying to recognize them at least), but it takes me to
> read about the theory about certain patterns. While I am more of a
> monkey see monkey do type of person.
>
> I put my arguments about the OOP approach, but that has not mainly to do
> with patterns. The thing is, you can factor things till you drop, but
> most code is still customization-greedy. I code the solution as where it
> is needed at a problem to be solved. I don't go all frenzy and think
> about all these hypothetical cases where a certain class would fit with
> thousands of exceptions and derivations etc.
>
> I mean, if you want to over-engineer you could write:
>
> <?php
>
> include('website_init.php');
>
> $website = new Website();
> $website->display();
>
> ?>
>
> Sure, it has a purpose, it looks clean, it is factored till I dropped
> etc. But for sure I have to open up some twenty files to even come close
> to the code that I've to edit to change a tidbit for a menu or whatever.
>
> Patterns can help with little parts of code, but even then I will come
> to cases where the pattern has to be changed a bit to apply it. I'm not
> sure I want to stick with a maze patterns and loose flexibility or
> creativity to think out of the box. Some people will start to say a
> solution is heresy just because a certain pattern is broken or it is not
> fully OOP or whatever. I want to be able to say: I solved it and it
> works. Next time it might not work, but I learned from the solution.
> Patterns or OOP tend to have a solution and a programmer should be able
> to fit that solution onto a problem.
>
> Is that weird to think that way?
well i think you half-way misunderstand patterns.. patterns are meant to be
altered slightly from their text book definition to fit into particular
situations.
for example, the proxy pattern is designed to restrict access to something,
what that is or how its restricted is not as important as that restricting
access
to a resource is a proxy..
beyond that, like i was saying before, adding layers of indirection for no
good
reason is clearly not a bright idea. as always, i will maintain that using
patterns
in reality is something that takes practice and studying, you need to try
things
and then see how they work out; see how they compare to other similar things
other people have done. that said, starting out, you might add something in
that is found to be unnecessary, which could impede an application in
several
ways, runtime performance and added complexity (which you mention) most
likely. what the patterns are there to help with though, is directly
binding code
together so that its hard to extend and maintain later on. this is a common
problem and it gets horrible quickly. what i see in a lot of real
applications that
ive worked on, is people just go in and start growing out these ridiculous
nested
conditional blocks, which is a maintenance nightmare.
patterns arent for everyone, and they are cookie cutter little things either
nor do
they only apply to oop (repeating things other have said i know). one thing
is
certain about patterns and that is you may be using them even though you
dont
realize it. this is why learning them is a great investment, it gives you
the power
of recognition and enhances your ability to communicate with other software
engineers.
-nathan
