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?
Aschwin Wesselius
<social>
What you would like to be done to you, do that to the other....
</social>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
