Re: OOP versus Procedural/Functional [message #177561 is a reply to message #177557] |
Mon, 09 April 2012 21:46 |
The Natural Philosoph
Messages: 993 Registered: September 2010
Karma:
|
Senior Member |
|
|
J.O. Aho wrote:
> Mr. B-o-B wrote:
>> I was curious about peoples thoughts in regards to OOP with PHP.
>>
>> Are there pro's/con's of writing OOP code versus procedural/functional
>> coding?
>>
>> Strictly speaking for PHP, I do the bulk of my coding as
>> procedural/functional. I really haven't found any added benefit to
>> going the
>> OOP route.
>
> There is two minds about OOP, there are those who thinks is the way to
> go and those who thinks it don't give any benefits.
>
>
>
>> Am I missing something, or is it just a different approach to the same
>> problem?
>
> It's another way to solve the problem and there is a third way which
> kind of mixes both worlds.
>
> Read some more about OOP in general and get a bit better insight for
> example:
> http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/oop.html
>
> The site may or may not be good, just got it as a hit on google, never
> read it myself.
>
> If you get an aha-moment, then OOP maybe is something for you, but if
> you feel it's just making things complicated, than stay with traditional
> functional programming.
>
> Many of the major big projects uses OOP, so it can be a good point in
> knowing how it works.
>
My research indicated that while it was definitely better for certain
things - VERY large projects being one of them, it wasn't worth the
hassle of doing it on small stuff.
I know of at least one company director who told me 'we wouldnt have
lost the business if we had decided NOT to write it in object oriented
code' By the time they realised the cruciality of proper pre code
object definitions, it was too late and you cant hack OO like you can
procedural.
I think if the project warrants the sort of intense functional
decomposition and 'objectification' process and there are dozens of
coders working on it, its a clumsier but more safe way to get slowly to
a working solution.
Like designing a database, you need to be clear on what objects you are
going to use and what operations you will perform on them and the
impact (relations) you want to have on other objects.
You can use an OO approach without actually using the language
extensions - E.g, in terms of files with defined (function) entry points
and static internal data..
The approach is worth studying: whether you want to force *all* your
code into the mould and/or use OOP language extensions is a moot point.
The step from machine code to assembler is like 100, from assembler to
macro assembler is like 10, from macro assembler to a language like C is
about 1 and from C to C++ is about 0.1 in my opinion.
I.e its a question of diminishing returns every time.
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|