3

I was asked to do a project in PHP and to make sure it was object oriented. I've done OO and I've done PHP, but never both.

The main benefit of OO PHP (outside of inheritance/polymorphism) seems to be code organization. That's fine; I'm doing that. But where I get stuck is if I should actually be creating instances for every "object."

To me (and maybe I'm being naive here), a web app is all about making very short, stateless requests to alter or retrieve records in a database. The objects can't persist between requests. So it feels rather pointless to load data from the database, construct an object from that data, make a small update, save the data from the object back to the database, and then throw the object away. The loading/saving code seems to be a lot of work for nothing. [clarification: a waste of development time, not processing time... not too concerned about overhead]

The alternative is to have a bunch of singletons (or classes with static methods) that just provide a nice, organized abstraction layer to the database layer. I guess writing code in this manner just doesn't feel truly OO. Am I missing something or is that style fine?

Jere
  • 3,377
  • 1
  • 21
  • 28
  • 1
    Sure, it's more overhead for the server. But the thing is that you need to look at if it is useful and easier for the programmer to maintain. Don't forget that programmer time is far more expensive than hardware costs. So if it adds a reasonable amount of processing overhead (it's not too significant), but saves a lot of development time (either initially, or in the long run), then it's worth it... – ircmaxell Nov 03 '10 at 22:57
  • You're absolutely right there. I'm not worried about the overhead anyway. Just wondering if there any benefit to one style versus the other. – Jere Nov 03 '10 at 22:59
  • 2
    Yes, forget about overhead or processing time. There's a few bytes of more memory use, but else totally negligible. While an all-OOP approach often stretches the paradigm into functionality where it makes no sense, it overall can make the domain logic more readable. So my suggestion would be to apply classes and objects where it benefits the API, makes it more coherent or understandable. For example for that database code it *looks just nicer* to use `$page->title` instead of `$page["title"]`. So, go for nicer. – mario Nov 03 '10 at 23:17

4 Answers4

6

Yes, you could summarise the benefits of OO as "code organization"; but this is true for all languages (not just PHP). In reality, it's more than that; it's about how you think about your data structures and algorithms, i.e. about how they map to concepts in the problem domain, how they relate to one another (ownership, parent-child, polymorphism, etc.), and how they expose clean, consistent interfaces to one another (encapsulation). If these concepts would benefit your application, and outweigh the extra development time vs. a quick-and-hacky procedural solution, then go for it.

I don't think persistence has anything to do with it.

I think you should question why you've been asked "to make sure it was OO". This seems like a pretty arbitrary request without further justification. Normally, the approach should be to write your application in the style that best suits the requirements, not arbitrary whims...

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
  • 'I think you should question why you've been asked "to make sure it was OO".' Of course I agree, but I feel like quite an amateur asking such a question. – Jere Nov 03 '10 at 23:02
  • @Jere: Not at all; I would always query unjustified constraints like this. – Oliver Charlesworth Nov 03 '10 at 23:05
2

I think OOP is just a programming style and has nothing to do with developing an application. What you need is a pattern that provides a sufficient abstraction layer (for example: MVC).

My recommendation is: Fat-Free.

It's tiny, simple and quickly take you to the minimal viable version of your product. It has everything that you might need (Caching, ORM, CRUD, Captcha...) and is so flexible that you can use any pattern and with your custom directories hierarchy.

Check out the extensive documentation. The only issue is that it requires PHP 5.3. I think it's reasonable considering the options and flexibility it offers. It really changes the way you work; you should definitively give it a shot.

Omar Abid
  • 15,753
  • 28
  • 77
  • 108
  • +1 for "just a programming style". Though I need to bicker about "MVC". Most web frameworks unknowingly follow PMVC or MVP actually. – mario Nov 03 '10 at 23:21
  • never heard of and google didn't help, can you give the whole word. – Omar Abid Nov 05 '10 at 22:48
2

Singletons are essentially just global variables with some namespace sugar added in. There are a few main benefits to programming with objects and classes that you just don't get from straight procedural programming. One is inheritance, as you mentioned. Another is the namespacing - you can have a code to compress the lot into a single include file (more meaningful in interpreted languages like PHP than in compiled languages).

Objects are essentially a collection of functions with a shared state (though singletons make that a global state. Beware.) As you pointed out the benefit is mostly that that state is transparently shared by the functions without needing to explicitly pass it every single call. If you have various functions per request operating on shared data and wish them to be specialized forms of a general set of functions, OOP is probably a good fit.

Since you have been tasked to "make sure it is object oriented", I'd take some time to consider common groups of functions, generalizations of same, etc.

In the end the setup/teardown time of the objects isn't too bad - and it might even save some development time in the future if you do a good job.

Iiridayn
  • 1,747
  • 21
  • 43
1

Like most things in life answer is somewhere in a middle.

Todays application use ORMs (for example doctrine for php) for different kind of optimization, better understanding of database approach (which is important for larger dev teams), easier update of the code, abbstraction layer that is well known to people who join the project, caching mechanisms,....

Classes with static methods are just fine if you are doing some smaller project on your own, but when more people are involved in progress you simply need something more robust and standardized.

trix
  • 1,110
  • 7
  • 9