On 7/25/07, Nathan Nobbe <quickshiftin@xxxxxxxxx> 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@xxxxxxxxx> wrote: > On 7/25/07, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx > wrote in message > > news:7dd2dc0b0707250839j4d43272boea44f0ccf5fe6148@xxxxxxxxxxxxxxxxx > > > eric is exactly right; design patterns are key; and so is that book ;) > > > > > > -nathan > > > > > > On 7/25/07, Eric Butera <eric.butera@xxxxxxxxx> wrote: > > >> > > >> On 7/25/07, Suporte - DPRJ Sistemas < suporte@xxxxxxxxxxx> 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. :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
