|
|
Posted by Jerry Stuckle on 11/08/07 13:38
lawrence k wrote:
> On Nov 7, 9:11 am, firewood...@yahoo.com wrote:
>> The next step, it seems to me, is to become much more skilled in
>> analyzing a program from an OOP point of view and learning the
>> techniques for organizing the structure of the scripts and how to
>> implement them in a website. In other words, I want to move from
>> amateur to pro in terms of both career and technique.
>
> Building something somewhat large scale (I mean non-trivial) in an OOP
> style is the best way to learn OOP. You'll make lots of mistakes and
> that will be educational. You can, at the same time, read about design
> patterns, and your reading should inform your code writing, and your
> code writing will give you an appreciation of the design patterns you
> are reading about.
>
>
Agreed.
>
>
>> Also, is PHP the best language to use to learn and implement the full
>> power of OOP? If not, any suggestions?
>
> Between 2002 and 2005 myself and some friends built a content
> management system using PHP 4. We were consciously designing as an OOP
> design. We used objects to mask the connections to the database, and
> objects to mask access to the server directories (only the code had to
> know where things were).
>
Two problems - a) You were using PHP 4, and b) you were relatively new
to OO.
Your lack of experience meant you didn't always know where the
bottlenecks could be, and how to avoid them. And since you were on PHP
4, you couldn't implement a lot of them anyway.
> In 2006 I came to the conclusion that the design was much too heavy,
> and all the masking had slowed things down. I've since been moving
> toward a style of coding that I think most people would find quite
> primitive - lots of plain PHP code right in the templates, nothing
> masked, everything plain, very little abstraction, lots of stuff hard
> coded. Stuff can be abstracted out once a project is mature.
>
Better to have a good design and abstract from the start. That way you
aren't rewriting your code all the time.
> The downside of OOP is that when a new programmer comes in, they've a
> harder time figuring out what is going on. Everything is masked and
> abstracted. The upside of plain, procedural code is that a new
> programmer can usually pick it up faster. This may not be an issue for
> you, but for me, being able to hand a project off to other programmers
> has been one of my top concerns, so I've come to favor plain code over
> OOP.
>
>
>
Properly documented, OOP is *much easier* for a new programmer, because
he/she doesn't have to worry about the internals. The interface is all
that's needed.
For instance - do you worry about the internal format of a floating
point number? Nope - it's abstracted for you. But you know the
interface - and can use them.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|