NYCPHP Meetup

[Chris Hubbard]

Brent,

There's nothing wrong with bright light and angelic music, as long as 
you can have a beer too.

My biggest complaint about the "technology" world is the great effort 
done by almost everyone to make things more obscure than they really are.

My description of OO is necessarily simplified.  When you've written a 
handful of classes you'll be ready for the next conceptual step.  It's 
not a conceptual leap.  But for now don't worry about it.   After you've 
refactored a class a couple times you get that elusive bright light, and 
all these weird OO concepts will start naturally, effortlessly making 
sense.  You'll get there, so enjoy the path, drink a beer, write some code.
Chris

Brent Baisley wrote:

> I just want to thank you privately for your excellent response. After 
> reading it, I almost feel like I've been through therapy. I've read a 
> lot about OO programming, design patterns and conceptual stuff, but 
> never sat down and gave OO programming my full effort. I feel I have a 
> firm grasp on the concepts of OO, but every time I toyed around with 
> it, it seemed more work than it should be, and certainly more work 
> than procedural coding.
>
> "Almost all the documentation... complicates the issue." Now I feel 
> I've been just overthinking things. I've been looking for the bright 
> light and angelic music, when I should have been looking for the cold 
> beer next to the keyboard.
>
> Many Thanks.
>
>
> On Feb 18, 2004, at 6:21 PM, Chris Hubbard wrote:
>
>> Heh.  You sound like where I have been. I spent a bunch of time 
>> trying to figure out OO, making myself crazy. Then it dawned on me 
>> that I hadn't had a need that OO would solve.
>> Most of my code used functions.   Most of my code used the same 
>> functions. So I started moving the functions into an included file. 
>> Then I had two files; one a bunch of functions, and then the code 
>> file. Then I started organizing the functions into different included 
>> files. So I had 6 or so possible files and one code file. Then it 
>> dawned on me that I was creating the effect of OO. So I rewrote the 
>> files that contained the functions, so each file became a single 
>> class, with a collection of methods instead of a single file with a 
>> collection of functions.  (note, as far as I can tell there's no real 
>> difference between a method and a function in php)  I had to go 
>> through and change some stuff, like using $this-> all over the place. 
>> When I was done I had a bunch of different classes that were a bit 
>> harder to use than the different include files.  After grumbling for 
>> a while, someone suggested creating a single error handling method 
>> that all the methods within a class would use. So now each class has 
>> integrated error handling (error reporting), instead of every method. 
>> Then I could add in things like a timer, debugging information.  
>> Refactoring the code across all the class-methods is easier than if 
>> they're just functions.
>> So:
>> procedural -> OO is pointless unless:
>> 1.  it makes it easier to maintain the code
>> 2.  it makes it easier to improve the code
>> 3.  it makes it easier to debug the code
>> 4.  it makes it easier to pick up girls
>> 5.  it makes it easier to show off at the users group (see #5)
>>
>> Almost all the documentation about OO complicates the issue.  It's 
>> really not that difficult.  If you're not understanding it, it's not 
>> because you're missing the OO bone/gene/hair.  It's because whoever 
>> is explaining it to you doesn't understand it well enough to explain.
>>
>> Relax, drink a beer.  It's not that complex.  If you're thinking hard 
>> about OO, you're doing the wrong thinking.  Save your hard thinking 
>> to solve the problem.  Once you've groked the problem the OO stuff 
>> will flow easily.
>>
>> Where to start:  take any single function and convert it to a class:
>> function print_array($array)
>> {
>>    print_r($array);
>> }
>>
>> becomes
>> class print_array
>> {
>>    function print_array($array)
>>    {
>>       print_r($array);
>>    }
>> }
>>
>> Both produce the same output.
>>
>> Hopefully this is clear and helpful.  Rather than obscure and annoying.
>> Chris
>>
>>
>> bpang at bpang.com wrote:
>>
>>> I've been "trying" to cross over, or at least start writing OO code, 
>>> for a
>>> long time, but I never can seem to fully catch on.
>>> I am pretty sure I could identify many instances where my code would
>>> benefit from OO, and I've been told that my procedural code is 
>>> written in
>>> OO format, just without the use of objects.
>>>
>>> This may be near impossible to answer, but, what would you say is 
>>> the key
>>> to "grasp the concepts behind OO" and to put it to use?
>>>
>>> I suppose if I forced myself to use it, I would probably figure it out,
>>> and I always feel a little "learning-disabled" for not having picked 
>>> it up
>>> yet, even after some tutorials, etc, but then Felix comes along and 
>>> makes
>>> me feel better about it...
>>>
>>> Felix said:
>>> "For most simple web based stuff you will almost never need to code
>>> objects yourself."
>>>
>>>
>>>
>>>
>>>
>>>> I think it is more than possible, though personally I prefer PHP to
>>>> Java, and for anything web-related I would almost certainly use PHP
>>>> rather than Java, purely because it is so flexible and easy to 
>>>> use.  As
>>>> for crossing over into OO, just take things one step at a time, 
>>>> once you
>>>> grasp the concepts behind OO you will see plenty of situations 
>>>> where you
>>>> could use OO design methods.  For example there are countless 
>>>> situations
>>>> where you can encapsulate functionality into a generic object, then 
>>>> use
>>>> inheritance to specialise that object for your particular needs.
>>>>
>>>
>>> _______________________________________________
>>> talk mailing list
>>> talk at lists.nyphp.org
>>> http://lists.nyphp.org/mailman/listinfo/talk
>>>
>> _______________________________________________
>> talk mailing list
>> talk at lists.nyphp.org
>> http://lists.nyphp.org/mailman/listinfo/talk
>>
>>