Re: Objects

On 7/25/07, Nathan Nobbe <quickshiftin@gmail.com> wrote:

Eric, i was referring to the exact book you mentioned. here is an excerpt from page 32 of the book: ' we assume you know the oo basics of using classes polymorphically, how inheritance is like design by contract, and how encapsulation works. if you are a little rusty on these, pull out your head first java review, then skim this chapter again.' so naturally, it follows that if you havent learned about classes, and how they can be related at a language level *first* design patterns might be a bit vexing. i would say to OP that if you arent going to get an oop book first at least read up on the oop section of the php5 handbook before getting started. and for your sanity dont bother w/ php4. btw. tonys work looks pretty solid to me. having come from a computer science background, taught computer science, worked w/ java and php and now studying design patterns i would say learn the basic oop stuff first ;) -nathan On 7/25/07, Eric Butera <eric.butera@gmail.com> wrote: On 7/25/07, Tony Marston <tony@marston-home.demon.co.uk> wrote:

Design patterns will just confuse the issue. If you come from a non-OO background (just like me) and want to know what all this OO stuff is

about

you might want to take a look at the following: http://www.tonymarston.net/php-mysql/good-bad-oop.html

http://www.tonymarston.net/php-mysql/hero-or-heretic.html

http://www.tonymarston.net/php-mysql/oop-for-heretics.html

http://www.tonymarston.net/php-mysql/what-is-oop.html

http://www.tonymarston.net/php-mysql/databaseobjects.html

http://www.tonymarston.net/php-mysql/databaseobjects2.html

I wrote these for the simple reason that, just like you, I found too

many

articles with lots of theory but no substance. Unfortunately too many of these theories conflicted with my past experience, so I chose to ignore

most

of them, and achieved far better results. You can download my sample application from

http://www.tonymarston.net/php-mysql/sample-application.html which provides

a working implementation which you can study at your leisure. -- Tony Marston http://www.tonymarston.net http://www.radicore.org ""Nathan Nobbe"" <quickshiftin@gmail.com > wrote in message

news:7dd2dc0b0707250839j4d43272boea44f0ccf5fe6148@mail.gmail.com...

eric is exactly right; design patterns are key; and so is that book ;) -nathan On 7/25/07, Eric Butera <eric.butera@gmail.com> wrote:

On 7/25/07, Suporte - DPRJ Sistemas < suporte@dprj.eng.br> wrote:

Hello! Is there anyone here interested in teaching (lond distance, off

course)

OOP?

I would like to learn how to use objects (I have been working all

my

life using structured language). All the books I have tried just

"talk"

about theory not practical issues.

I intend to pay for the classes. Thank you Deleo

Do yourself a favor and read up on "design patterns." I think that they go hand in hand alonside learning OOP. The reason I say this is because people can talk about encapsulation and polymorphism all day long, but until I see some concrete examples with real world implementations it won't stick in my head. I really enjoy this book:

http://www.oreilly.com/catalog/hfdesignpat/

It is for Java, but the idea behind patterns is that they are ways of doing things and not syntax. This means that you aren't really tied to any given language because once you know how to build a factory

you

just implement the best way you can given the structure of the language. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

If you read the book I pasted a link to it would make perfect sense. It goes from the beginning to the end show exactly what the decorator is, why you would use it, and how to use it. It isn't just saying here is a decorator. It uses a real world example and a real world solution. Even if you don't know programming the examples are so straight forward with illustrations that if you think you get it. Now if you just look at some quick example then sure, they are very confusing. It might just seem like way more code for no apparent reason. That is why books sell though. The authors put lots of energy into making the ideas make sense rather than throwing psudo-code at you. I've seen your posts here before and I know you are very set in your opinions on what is "right" and "wrong." I think you should just consider for a minute not all people think along the same lines as you or myself. I also came from a procedural background where $this confused me to no end. Then I found the factory pattern and saw that was useful for database things. After that I realized I could do all sorts of neat things using the concept of having interchangable parts. At first I didn't know it was called a "factory," but just saw that it was great being able to call a method to get different drivers. Later on after I discovered there was a name, patterns, for these reusable ideas it just kept getting better. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Fair enough. :)