Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
PHP Books Media Programming Book Reviews

PHP 5 Objects, Patterns and Practice 165

Posted by timothy from the at-length dept.
Daniel Holmes writes "In addition to using PHP to 'just get the job done' for years now, I've been running a humble user group here in the Midwest. As such, I have read numerous books on and around the subject, always looking for something great to inspire my colleagues, group members and myself alike. There are a metric ton of books out there that will walk you through PHP syntax -- this is not one of them. If you are looking for a book on rapidly developing prototype sites, or writing lots of HTML-embedded PHP, just keep looking. But if you have read even one of those books, or just felt like your programming style itself could use a little upgrade, then go get yourself a copy of PHP 5 Objects, Patterns, and Practice by Matt Zandstra." Read on for the rest of Holmes's review.
PHP 5 Objects, Patterns and Practice
author Matt Zandstra
pages 437
publisher Apress
rating 10
reviewer Daniel Holmes
ISBN 1590593804
summary A powerful tour though PHP 5's object-oriented features; leveraging the power of design patterns and developer best-practices.


For around 40 bucks, you will get a book separated into three main parts, as the title suggests; plus an Introduction, Conclusion and Appendix. However, you also get an amazing level of detail, insight, and plenty of lessons from the (even non-PHP) programming greats. In just over 400 pages I saw hints as well as direct references to some of the best texts in the business: The Pragmatic Programmer, "the GoF", "Enterprise Patterns" and a host more that I will touch on later. The point is: if you have seen true object-oriented development, and have had trouble using these concepts in PHP; don't despair any longer. Matt has done all the work for you--all you need is a weekend or two to do a little reading.

Part I - Introduction

As you would expect, Part I really sets the stage for the whole book. It points out where the typical state of PHP development is, and (frankly) why we all need to read Matt's book. He does this by telling a great story of a project life cycle gone badly. As many of you know, systems are easy as they are small, but as they grow things often get out of control without proper care and feeding. This section is important as so many good PHP developers don't even know why their code has grown so rapidly out of their control. Don't skip it, even if you know better.

Part II - Objects

In Chapter 2, we read the story of the evolution of PHP as a language -- specifically in regards to its object-oriented (OO) constructs. This is nice in that the author presents it in a way so as to not insult the procedural crowd -- something I often struggle with around this topic. Matt's writing style is immediately approachable; he does not come off as the pretentious object-oriented zealot you might expect from the lengthy title.

You also learn that his lessons will take you way beyond just the syntax. Knowing the ins and outs of PHP's oo syntax is not enough: "You must first choose the right participants for your system, and decide the best ways for them to interact." Now that's something you rarely get in a PHP book.

In Chapter 3, we begin to review the new syntax introduced in PHP 5; just to make sure we are all on the same page. One nice feature here is that Matt uses "sidebars" to point out everything that isn't available in PHP 4. This makes it easy to pass over if you are starting with PHP 5, but it also makes the information available for the rest of us.

It is important to note that this chapter gradually and effectively introduces the layers of OO syntax available in PHP 5. Each lesson or feature simply builds on the next. This makes it nice because you can stop, try things out, read some more, etc.

Chapter 4 takes us a little deeper into PHP 5's OO syntax. It is quite helpful that Zandstra breaks up Chapter 3 and Chapter 4. If you are new to OO syntax, the end of Chapter 3 makes a great place to stop and reflect for the night. Seriously, go to bed and let it sink in.

As you can imagine, the "Advanced Features" include concepts such as:
  • Static methods and properties
  • Abstract classes and Interfaces
  • Error handling and Exceptions
  • Final classes and methods
  • Interceptor methods aka "Object overloading"
  • Destructor Methods
  • Object Cloning
  • The magic __toString(): converting objects to strings.


These are not particularly easy topics to master the first time you hear them. However, I think Matt finds a great balance of code and presentation to get the ideas across.

His section on Exceptions alone should be required reading for anyone using PHP 5. Again, not only does he show what they do, he really explains how they will actually help you out.

By the time you get to Chapter 5, you are ready to learn a handful of tips and techniques you can use to keep yourself out of trouble. First off, as PHP is lacking support for true namespaces, Matt shows us the PEAR method of using naming conventions to avoid namespace conflicts. We also learn about using include, require and the new (and possibly controversial) __autoload() function. Of course, there are pitfalls with nearly all of this, and Matt makes sure we know them before we leave the chapter.

Finally he walks us through various reflection techniques. Naturally, starting with simple, function-based reflection. Then taking us through a very complete tour of the new class-based, Reflection API. If you haven't used this, it is a very clean way to expose every nook and cranny of your objects and classes at runtime. Something that can save your sanity in a language that lets you change your API on the fly. Again, it's not just a bunch of talk; there are plenty of great examples to get you there.

By the time you get to Chapter 6, it is time to take another break. Better yet, if this is all new to you stop and play with the code for a bit. Sure you could keep reading, but it will really help if you have the syntax and concepts down so you don't keep flipping back.

Again, Zandstra doesn't just jump straight into design examples; rather, he walks you through why you should even care. Sure, many of us have features in mind and run straight for the finish line ... but this can really get painful on older systems. He even takes a moment to point out one of the biggest traps for developers new to OO. "The presence of classes does not guarantee object-oriented design, even in languages like Java, which forces you to do everything in a class."

The chapter hooks you right away with an example done procedurally and another in OO using appropriate abstract methods. The point is clear: with proper design, you can get away from the Giant If-Else Blocks of Doom and pave the way towards actually keeping up with your client's requests.

Finally, he defines and relates the concepts of Responsibility, Coupling, Cohesion and Orthogonality.

Another great nugget of advice has been planted in this chapter. According to Zandstra, the art of selecting and defining objects "...is far more than just finding the 'things'" in a system. "If you see a class as a noun, a subject for any number of verbs, then you may find it bloating as on going development and requirement changes call for it to do more and more things."

Never before have I seen a simple sentence more completely dispel the inappropriate "object oriented" lessons you may have learned in school. If anything; if you find that it hits too close to home, you will pay attention to what he is about to say!

After telling a story about classes gone badly: "How should we think about defining classes? The best approach is to think of a class as having a primary responsibility, and to make that responsibility as singular and focused as possible. Put the responsibility into words." He continues, referring to the writings of Peter Coad: "If your sentence gets too long, or mired in clauses, it is probably time to consider defining new classes along the lines of some of the responsibilities you have described."

Our tour continues through the basics of polymorphisms and encapsulation. After which, Matt provides us with "four signposts" to help identify problems that can creep into our designs:
  • Code Duplication
  • The Class that knew too much
  • The Jack of All Trades
  • Conditional Statements


For more detail on these tell-tale signs that are probably represented somewhere in your code, go buy the book.

Matt really surprised me in this chapter. After getting us up on all the OO syntax and concept basics, he pulls out the UML. What was so surprising is how easy and approachable he made this introduction. In just a few pages, you learn enough to diagram and interpret inheritance, associations, aggregation and composition, and actually know what all that means. As an added bonus, he even gives a useful introduction to sequence diagrams.

Now, a chapter on UML (or some diagramming set) is usually included in any pattern book. But, this is different from those others. Matt provides s a short, easy to understand introduction to just enough UML to communicate your concepts and processes. A very cool bonus indeed.

Part III - Patterns

As Matt says in chapter 1, this book stands on the work of giants. He makes this obvious in parts III and IV. While some may say that he is just repeating what others are saying, I would disagree. The value he adds in basing the patterns in examples you can actually picture writing yourself is worth every delicious page.

After walking us though the why-and-how of how "design patterns" came to be, Matt again makes us actually care about spending the time to learn as many as possible and to use them when it is appropriate. Again, he does a great job of breaking these tough concepts into bite-sized chunks. Don't get me wrong, though; you'll be full after reading the chapters in this section.

I won't go into great detail, but I need to at least provide you with an idea of the patterns you will learn about in this section.

In chapter 8, Matt describes some of the most low-cost, high-return concepts around: composition, decoupling, "patternitis" and the golden rule of OO development -- "Code to an interface, not an implementation."

In chapter 9 he introduces us to some "creational" patterns: The singleton, abstract factory, factory method and prototype.

Chapter 10 focuses on "structural" patterns. The ones he focuses on are the composite, decorator and the facade.

You should note, most of this is PHP written as if we were developing a civ-style, Web-delivered game. This is much easier for "the rest of us" to digest and apply these examples than the GoF's examples of building a large-scale word processor. No disrespect to the bible that is the GoF, but if you have read about design patterns, and still need a little help applying the ideas to your day job, parts III and IV were written for you.

Chapter 11 introduces us to some great task and message management patterns: Interpreter, Visitor, Strategy, Command and Observer.

Finally, Chapter 12 drives us home and provides us with a great look at even more great patterns and explains how they fit into the three tiers of sustainable web development: presentation, business logic and data retrieval and storage.

Presentation
  • Registry
  • Front Controller
  • Application Controller
  • Templates and Template Views
  • Page Controller
Business Logic
  • Transaction Script
  • Domain Model
Data Access and Storage
  • Data Mapper
  • Identity Mapper
  • Unit of Work
  • Lazy Load


Part IV - Practice

This is a very important section: like the intro, please don't be tempted to skip it. Matt reminds us while learning code and code design is great, it teaches you nothing about the day-to-day tasks associated with actually keeping the project alive and kicking.

In "Borrowing the Wheel," he shares with us a fantastic piece of advice; one that many PHP developers could stand to listen to:
When this temptation [to reinvent the wheel] comes over me I remind myself of projects past. Although the choice to build from scratch has never killed a project in my experience, I have seen it devour schedules and murder profit margins. There I sit with a manic gleam in my eye, hatching plots and spinning class diagrams, failing to notice as I obsess over the details of my component that the big picture now is a distant memory (p. 294).


Please, take another moment to read that again. If this sounds eerily familiar, please stop reading my review and head strait for your nearest book dealer.

In these chapters we naturally get the (hopefully) obvious hints: use version control, write tests, use PEAR, etc. But, where else will you find all this along with excellent references on actually using PHPUnit2, writing your own PEAR Packages for managing even your own code, actual phpdoc syntax and examples ... not just the act of documenting your code, but using the phpdoc command line tool. And with the section on using cvs, you will have absolutely no excuse but to save your life with some form of version control.

Matt even devotes an entire chapter to managing automated builds with Phing, the PHP equivalent of Apache's ant or C's make.

Most of this information is available in countless forums, articles and websites where you could learn about all of these topics for "free." Or, you could read this section in an afternoon or two and begin amazing your friends and better managing your code right away.

Part V - Conclusions

Matt's summary and overview is a great recap of the journey he has put us on. But, on top of that, he outlines some of the essentials that he had to leave out. Here he at least mentions the importance of tools such as bugzilla, mail lists and a wiki for all that other documentation.

Looking at the Bibliography (and all the places he gives credit where credit is due) is like looking at the reading list of nearly every great programmer. You will find books such as: Core J2EE Patterns, Design Patterns (GoF), Extreme Programming Explained, A Pattern Language, Patterns of Enterprise Application Architecture, The Pragmatic Programmer, Refactoring and UML distilled. This is, of course, along with many on-line articles and websites.

Sure, you could spend years reading all of these sources (and some you still should) but unless you get paid to read, do yourself a favor and get some of the best of all of these texts, tailored to you in PHP and delivered in just over 400 pages.

My General Impressions



As I mentioned earlier, one of my favorite features of this book is that the examples are "real." This is not some collection of abstract examples like building the next great competitor to Word -- these are website concepts we mere mortals can relate to, such as product catalogs, games, invoices, and the like. You know, the stuff we actually do for a living.

This book does not cover loops, conditionals, functions, operators or any of the non-OO basics of PHP, and believe me, I am grateful. If you would like an introduction to the language of PHP, simply check out php.net or one of the many great introductory books.

I would certainly recommend this book (as if there was any doubt) to any PHP developer. This is especially true for anyone interested in learning more about using objects and classes more appropriately than ever before.

I would also recommend this book to any Java, Ruby or Python developer out there who hears the letters PHP in a sentence and immediately responds with any number of colorful phrases. As we have all read the Pragmatic Programmer by now, we know we can learn something from reading up on any language, and PHP has never been better than it is today.

Finally, I would tell any web application developer who is looking for a quick way to absorb and comprehend the meat of some of the best development and design books ever written.

Read it for yourself and I think you will agree: the desk of nearly every PHP application developer will one day be holding a copy of this book.

Daniel Holmes maintains the PHP User Group in Kansas City since its inception in 2000. He is also the Systems Integration Manager at JCCC in Overland Park, KS. You can purchase PHP 5 Objects, Patterns and Practice from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

PHP 5 Objects, Patterns and Practice More

PHP 5 Objects, Patterns and Practice

Comments Filter:

  • Nice (Score:2, Funny)

    by Programmerangel ( 882072 )
    Hmm...seems like an interesting book. Glad I learned the language last week. :)

  • Seems a lot like... (Score:3, Informative)

    by op12 ( 830015 ) on Thursday August 18, 2005 @04:04PM (#13350910) Homepage
    the Spring Into PHP 5 [slashdot.org] book reviewed here earlier recently.

  • I like... (Score:2, Informative)

    by theotherlight ( 904426 )
    WROX's Professional PHP 5.

    This book sounds a bit more technical, but I've always loved WROX's style of writing.

  • "the GoF"??? (Score:4, Informative)

    by Anonymous Coward on Thursday August 18, 2005 @04:11PM (#13350972)
    The Gang of Four is not a book. They are four guys who got together to write a book, and an excellent book at that: Design Patterns - Elements of Reusable Object-Oriented Software.

    In no particular order (other then that which appears on the front cover of Design Patterns), the Gang of Four is:
    • Erich Gamma
    • Richard Helm
    • Ralph Johnson
    • John Vlissides

    • sure, pedant (Score:3, Informative)

      by jbellis ( 142590 )
      but just about everyone refers to that book as, well, The Gang of Four.

      it's like the Dragon Book, but that's probably before your time.

      sorry to burst your bubble...

      • it's like the Dragon Book, but that's probably before your time.


        I was really sad to see the new Compilers book no longer has a dragon on it.

        The dragon book is the only textbook I still have from college.
    • an excellent book at that: Design Patterns - Elements of Reusable Object-Oriented Software.

      Having just taken Ralph Johnson's excellent Object Oriented Programming and Design class (CS598) at U. of Illinois, I'd just like to second the quality of the material in Design Patterns.

      While professor Johnson's class gave me a love for Smalltalk, I make heavy use of the patterns in my daily work developing PHP apps. Though PHP4 has a comparatively crappy object sytem, they patterns are still workable for the most pa

      • Re:"the GoF"??? (Score:3, Informative)

        by Frymaster ( 171343 )
        Though PHP4 has a comparatively crappy object sytem

        "comparitively crappy"? while i love php4 for its lightening-fast dev time and embarassingly forgiving syntax, it's oop implementation is far and away the worst i have ever seen.

        php started life as a procedural language, based on the ideology the that primary component of web development was the "page" or even the "session" and that adding another logical component system (the "object") was pointless. the oop capacity of php4 was little more than a gros

        • I agree with everything you've said (I've been using PHP since PHP/FI).

          But in the authors' defence (just for the reading public, not you--you don't seem to be slamming anyone), they agreed with you too. They made no bones about the fact that PHP 4 objects were essentially arrays which could contain functions, with some sugar like inheritance thrown on top for flavour.

          Some of us in the PHP community, on the other hand, might have gotten a tad overexcited. :)

          Torben
    • In no particular order [...]

      Alphabetical. That's particular! :)
  • This book must be HUGE! Look how big just the review is!

    Joking aside, thanks for the tip. I'm also always looking for good resources, and am a huge fan of PHP for development (especially after having to recently fix a hellhole of an ASP site). This comes at a good time with the impending release of a stable PHP 5. Thanks again.

    • Re:Book Review or Book (Score:3, Informative)

      by WiFiBro ( 784621 )
      I agree, this is a bit too long for a review, it's almost a book, and where's the criticism?
      What do I do with a comment like "a very useful something-to-string-function in chapter X"
  • ...for IBM developerWorks recently; here's his two part series on objects in PHP (part 1 [ibm.com] and part 2 [ibm.com]).

    If you like to write tech articles, I recommend dW; they're a good crew. Some of their tutorials (like my GLib collections tutorial [ibm.com]) require registration, but, hey.

  • tell us (Score:2, Funny)

    by adnausium ( 901852 )
    why doesnt Daniel tell us how he really feels...
  • and I'll be modded troll again.

    "PHP: Because 1,000,000 newbies can't be wrong."

      - Someone, not me.

  • Web design and objects (Score:5, Interesting)

    by acomj ( 20611 ) on Thursday August 18, 2005 @04:27PM (#13351085) Homepage
    I find very little use for objects when I write Php.
    (except the very nice "smarty template" engine)

    I don't know why, because I program with objects all day at work, but for web design, they don't stick around between page loads (unless I'm missing something, Ajax et all). I use sessions all the time though. I find procedural stuff much snappier than recreating the class each time.

    • It depends on the size of the project I find.

      All my PHP is completely OO.

      For larger projects it can make manageability a lot simpler, as you probably know from your work ;)
    • Of course objects 'stick around between page loads' - just store them in your session and restore them as the first action on the loaded page. If you don't use sessions because you dislike cookies, just configure your PHP to use server-side sessions by default or cast the unholy INI set rune to override the unfavoured default.
      • Doing that still means the object is being serialized and saved in a file when the script ends, the object class is included and parsed again the next time the script runs and the object is unserialized and "recreated". That's not "sticking around between page loads"...

        ---John Holmes...
      • But page loads suck. I hate to see pages crawl as they load; it's painful to watch. I know that this is a problem with the static web space in which we work, but it's a tremendous annoyance. I'm currently working on a development environment for PHP5 that will attempt to keep PHP applications "open", in so far as the developer sees the program. Imagine a case where the developer is coding an application that needs to attach an event to a button. For instance:

        <?php

        class ButtonApplication extends GFrame {

    • What you really need is a development framework to build your classes around that allows for persitence. The page based, highly transitive web model is broken, and Ajax works around that.

      If you put your objects in a framework which supports persistence, then old code works the same as it always has (with a potential performance boost) while allowing Ajax based applications to communicate with the object over the course of a session.
      • What you really need is a development framework to build your classes around that allows for persitence. The page based, highly transitive web model is broken, and Ajax works around that.

        I agree, except you're mixing two unrelated ideas. AJAX is just a method for communicating with the server that doens't require the browser to reload the page. The server could be anything under the sun, with or without persistence.

        In response to the grandparent, the idea that you need persistence to make OOP worthwhile i
    • I used to feel the same way until I got a second programmer on board and he was well-versed on PHP from the object-oriented side. Sure, it is a web-based application and there is no state, but the OO approach can save you a hell of a lot of trouble. Done right it saves you a lot in redundancies, plus as long as you don't mess with your interfaces you can work on the object itself without messing the pages that use it.

      Imagine an online community. Your user profile keeps 10-20 bits of information about each u

  • a short article from same author (Score:2, Informative)

    by Anonymous Coward
    http://www.zend.com/php/design/patterns1.php?print =1 [zend.com]

    You can get a taste of his writing skills which are pretty straight forward.

  • At this point if I were just starting out in Web development, wouldn't I want to invest in learning Ruby on Rails instead of PHP?

    PHP had it's time. That time is now seems to be passing. For everything there is a time and a season: Now it seems to be the season of Rails.

    • Re:PHP vs. RoR? (Score:2, Informative)

      by Philmeeh ( 189317 )
      You're forgetting that there are far more web hosts providing PHP than Ruby / Ruby On Rails. I am currently learning Ruby and Rails at the moment and did a quick trawl of web hosts forums and in every support forum that asked for possible support for Rails there was just the question "What is Rails?". PHP on the other hand is well known and has a lot of famous applications for it.

      If you have control over your own server environment it could well be worth swapping to Ruby & Rails.
      • You're forgetting that there are far more web hosts providing PHP than Ruby / Ruby On Rails.

        Which doesn't really matter if you're willing to shop around. I've found several inexpensive hosts that support Django, which hasn't even had a stable release yet. I'm sure you can find hosts supporting Rails.

        Sure enough, the Rails guys even have an official host [textdrive.com]. Reasonable prices.

        • Yes but the majority of people won't shop around - they may already have a host that supports PHP. So they are more likely to say 'I may as well learn PHP'. It's that whole chicken and egg scenario.

    • Re:PHP vs. RoR? (Score:3, Informative)

      by ciroknight ( 601098 )
      First of all, that third-to-last sentence was barely parsable, but I gotcha.

      Secondly, PHP and Perl are like the C and C++ of the web world. They're the oldest and most trustworthy platforms available now, and now since PHP has joined the ranks of full object orientation, it can be a serious competitor to VB/.Net.

      Too many websites, web applications, corporations, banks, etc. rely on PHP for it to just die. Ruby on Rails may be better, but it's very much a niche product, and it will take it a lot of tim
      • I'm sorry, I know this is totally trolling, but FEARCE...bahahaha

    • Re:PHP vs. RoR? (Score:5, Insightful)

      by Mr. Slippery ( 47854 ) <tmsNO@SPAMinfamous.net> on Thursday August 18, 2005 @05:23PM (#13351444) Homepage
      At this point if I were just starting out in Web development, wouldn't I want to invest in learning Ruby on Rails instead of PHP?

      No, you wouldn't. PHP has a massive installation base, it's not going anywhere. RoR shows signs of being just the latest the flavor of the month, but even if it does persist it's a framework, not a language - works great if what you want to do fits into that frame, otherwise you spend your time trying to bend the bars of the cage.

      • "[Ruby on Rails] works great if what you want to do fits into that frame, otherwise you spend your time trying to bend the bars of the cage."
        Could you share some examples of cases where you've found the Rails framework (or the Ruby language) to be too restrictive? It sounds like you're speaking from experience, and I'd like to hear about your experiences.
      • PHP has a massive installation base, it's not going anywhere.
        On that note. Let's all keep running Windows! As a person who has stopped working in PHP and has moved his business and new clients to Ruby on Rails... I can assure you, Rails is going to be huge in another year. :-) (at least it better be... ) ;-)
      • I was implementing some coding algorithm that required using an unsigned int. Believe it or not there is no way to create or use an unsigned int in PHP (I even tried "faking it" by twiddling the most-significant bit of a signed int by ORing with a known value, but I just couldn't fool it)... but Ruby has that capability. So I successfully implemented the algorithm in Ruby, really started to like the features of the language a lot ("everything is an object" is actually pretty nice; data that comes from the o

    • Re:PHP vs. RoR? (Score:3, Insightful)

      by WWWWolf ( 2428 )

      Learn both. Or, I'd recommend learning stuff in this order: PHP (the basics of web programming or "what is this HTTP thing anyway"), PHP+Smarty (how to separate the Content from the Logic), and Rails (fimally, a sane programming language with a full-blown MVC separation). Or, alternatively, Perl, HTML::Mason, Rails.

      A beginner to web programming will probably look at Rails with the same way a beginning mountain climber will look at Kilimanjaro*. You can learn Rails first, but it's a whole new world to itse

    • Tired=RoR
      Expired=PHP 4

      Get with the program already:-)
    • At this point if I were just starting out in Web development, wouldn't I want to invest in learning Ruby on Rails instead of PHP?

      I've been thinking about this too, but PHP seems to win hands down in the deployment category. It looks like a lot of Rails apps use lighttpd, but a lot of people are very happy with Apache.

      You can use mod_ruby, but this gets tricky with multiple applications on the same server instance. The "preferred" deployment method seems to be FastCGI, but this seems like a strange option to

      • There's a lot that Rails does right, but I'm not yet convinced it's the only reasonable optional for medium-sized apps. Of course, this gets a bit muddle because we're really comparing a framework to a language.

        Okay, let's compare the object-oriented power of Ruby to the nice oo addons that PHP5 has given us.

        Ruby > PHP5 (in terms of OO)

        Therefore, it is likely that any framework which fully utilizes that power (Rails) is a more powerful object-oriented framework. This is just a generalization...

        • Ruby vs PHP. Aside from a large userbase and a bunch of legacy php applications, what does PHP have over Ruby?

          Going back to my first post, I think the biggest thing is that PHP has deployment absolutely nailed. PHP is easier to deploy on your own server, and practically every hosting company in creation supports it.

          I have reservations about FastCGI and mod_ruby apparently isn't all that safe (if I want to use Rails). If I need to stick with Apache, what do I do?

          In terms of the language syntax (perhaps this

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Thursday August 18, 2005 @04:37PM (#13351159)
    Comment removed based on user account deletion

  • Patterns (Score:2, Informative)

    by spiffy_dude ( 762559 )
    I believe every single one of the patterns mentioned above share names with patterns out of the book by Martin Fowler (and company): Patterns of Enterprise Application Architecture. I'm not sure I would be as unqualifyingly kind as the author of this review about regurgitating them. They are great patterns, but is a PHP-ized version of these patterns worth the price when it's such a major part of the book?
  • What is this PHP you are referring to?

    </sarcasm>
  • I've flicked through this book at work - overall it is a great book but it isn't the best book to learn Design Patterns with. I would suggest "Head First Design Patterns" by Freeman and Freeman. The examples are in Java but it should be fairly easy to port the patterns over to PHP (plus it will build up your experience with PHP5 Object-Orientated programming). You can find out more information about the Head First Series at Wickedly Smart.com [wickedlysmart.com]

    • Java? (Score:1)

      by mfh ( 56 )
      I'm not going to mince words. I think that if you have a book on Java, it really only applies to Java. Anyone can claim a book will apply to other languages, but some differences could cause confusion and hours of lost productivity. I might read the book you suggested but I wanted to make it clear that I would be only reading it in terms of Java and not PHP. Mixing languages is what causes so many compsci students to skip class and play Quake.
  • If you live in the san jose area, and you'd like to meet about PHP/Mysql, check out my post, and left a message. http://www.somejunkwelike.com/wordpress/2005/03/07 /south-bay-php-user-group-meeting/ [somejunkwelike.com]
  • It's not that hard, man..
  • ativity in here? what gives? - if you dont like the review, php or life in general please give some intelligent reason as to why.

    I thought there was a higher level of respect at slashdot... guess i am showing my n00b.

  • Upgrade your programming style (Score:3, Interesting)

    by MourningBlade ( 182180 ) on Thursday August 18, 2005 @08:19PM (#13352367) Homepage

    If you'd really like to upgrade your programming style, why try a real book [paulgraham.com]?

    I see so much stuff about writing better OO code, better Java, better PHP...hardly much at all about changing the way you think about programming. I know it's written about Lisp, but it's a book about high-end coding - about what being a master at code is all about.

    Free download here. [paulgraham.com]

    • Lisp is a most excellent language, and On Lisp is a very good book.

      It may be an uphill battle to see Lisp become popular, but even if you doubt that you would be able to use Lisp in any real projects, I would still highly recommend spending some serious time learning Lisp.

      Perhaps devote time to studying Lisp over the course of a year or two. Why so long? Because Lisp is so different. Unless you already know functional programming, you probably won't digest it all in a week or two.

      Take a look at Paul Grah
  • Beware that if you plan to run PHP5 on a large scale, you really need to buy Zend Platform ($1500 per multi-cpu server). Running a large application without an opcode cache requires ALOT more memory, and the free opcode caches (apc and eaccelerator) do not optimize PHP5's new object syntax well, if at all. Do some simple testing on such an app with memory_get_usage() or a debugger and you will quickly see what I mean.

    I was looking at PHP5 as a platform for a rails-like MVC framework, but it would cost ove
  • what'd i'd really like is a perl book on the same topic...does anyone have suggestions?

Slashdot Top Deals

"We live, in a very kooky time." -- Herb Blashtfalt

Close