4

Is it wise to start with object-oriented PHP by using classes as a collection of methods? Are there any drawbacks with this approach?

I know OOP is much more than this, but my PHP-projects are too small to take advantage of all that OOP has to offer. On the other hand, my projects are becoming too big to update/maintain just with procedural programming.

I have read many topics about OOP and once in a while somebody says "OOP is more than just a collection of functions" (or something along these lines). It made me think: that may be true, but it also may be my chance to finally dive into the world of OO-programming by doing just that.

So, is this a smart first step to actually start using and learning OOP? Or are there serious drawbacks I need to know about?

Abe1984
  • 101
  • 6
  • 2
    If it helps you writer better code, why not? – phant0m May 04 '13 at 11:47
  • 1
    That is not object oriented programming (at all), that is call classed based programming. You might want to learn about the [utility pattern](http://c2.com/cgi/wiki?UtilityPattern) and see [Utility classes are evil?](http://stackoverflow.com/q/3340032/367456) - keep in mind that different programming languages have different needs. In PHP you should learn about the different of static and dynamic method calls. – hakre May 04 '13 at 12:01
  • 2
    If you want to take this approach, just get a [good book on refactoring](http://martinfowler.com/books/refactoring.html) and apply what you learn on the way. You'll eventually write better code. – Yoshi May 04 '13 at 12:09

6 Answers6

2

Your question is real broad, however it deserves a simple answer you can memorize and keep with you while you continue your journey into the world of object oriented analysis and design (OOAD).

So, is this a smart first step to actually start using and learning OOP? Or are there serious drawbacks I need to know about?

As you can imagine, it is not possible that we answer this question directly. What is smart and what not depends a lot of our own abilities. E.g. for some persons it might be smart, because it helps them to stop errors early and this is the way to go. For others, it might be the complete desaster, because they don't spot any error, continue developing a software because they think: If I don't spot an error, this is totally right.

So how to resolve this dilemma? Easy, we have two parts in OOP you can easily learn about and keep with you. The first is called S.T.U.P.I.D. - you might imagine what it means if something falls into this category, and the second is called S.O.L.I.D. and it's likewise self-speaking how to treat the somethings in there.

hakre
  • 193,403
  • 52
  • 435
  • 836
  • My broad question deserves an "it depends"-answer. Thanks for the link with the easy-to-remember guidelines. – Abe1984 May 04 '13 at 12:55
2

Disclaimer: I haven't dealt with php in a while, so my syntax might be wrong.

The term OOP is a bit fuzzy imo, meaning that different people will think of slightly different things when they hear it, so don't be confused when you hear contradictory things about it.

Structuring similar functions together using classes won't hurt your code, but then you basically just use classes as namespaces for your functions. Usually, you will want to define classes in a way that encapsulates some aspect of your system, meaning that only the code of that class will ever have to deal with that aspect directly, and everyone else just uses that class.

For example, you could have a class that manages a print job queue. If you have some code that wants to print a document, it doesn't have to know how or where the jobs are queued or how they are sent to the printer, it only needs to know a print job queue object (let's call it $jobQueue), which might have a method like $jobQueue->enqueue($document).

Now you might argue: "That code could just as well use a global function enqueueJob($document)," and that is true until you want to have more than one queue (for different printers), and queues that work in different ways (store jobs in a database, in memory, or not at all - imagine a queue that goes right to the recycling bin :)). With OOP, this kind of scenario is no problem, and these details stay completely hidden from the code that wants to print a document - all it has to care about is that it has a job queue object with an enqueue method.

To get this kind of "interchangeability" of job queues they need to have a common interface (in this case, the enqueue method,) which has to be carefully chosen to cover all the needs of the code that wants to print things, but without making too many assumptions about how a print queue works. For example, you could imagine that the enqueue method takes a file path as argument which tells the queue where to store its files - but that interface would be useless for a queue that works on a database. This is the art of finding good abstractions.

Now to come back to your original question, just packing related functions together into a class is not really OOP in my opinion, as long as there is no thought about which abstractions / interfaces the new class is supposed to provide. Without that, all code that uses this new class will be hardwired to use it, and will need to be changed / reexamined if you ever decide that you DO need a different kind of printer queue. :)

However, "not OOP" is not the same as "not a good idea". I say go for it and rearrange your functions. In my opinion, it is important to keep in mind that not everything needs to be an object or fit some abstraction. But maybe you will find out that you do have some functions which do similar things (queue in file, queue in database) which could be abstracted to a common interface.

Medo42
  • 3,821
  • 1
  • 21
  • 37
  • Thanks a lot. Your answer does not only clarify "abstractions" and "interfaces" for me, but it also gives me the confidence that I am on the right way. – Abe1984 May 04 '13 at 13:32
1

OOP is basicly just set of methods. But thinking in programming is different. In classes, you encapsulate similar funcionality. Code is more readable, you dont need to write same functionality over and over again. It is also more secure (private members), if you are writing library, end-user can change only what you want etc. So I wouln´t recomment to try bypass OOP with set of functions and use real OOP instead. There is no reason why not.

Martin Perry
  • 9,232
  • 8
  • 46
  • 114
1

I don't recommend, you will get used to write procedural code masked as OOP, which is not really what you want. Could be hard at first, but learn OOP with all it's features, read about patterns, emphasise on coding standards and, most important, study applications with object-oriented architecture.

Corneliu
  • 1,110
  • 1
  • 10
  • 16
0

Some things are functional, procedural and based on an object. Use the one that is the most appropriate for the circumstance. You will not got far wrong with that philosophy.

Ed Heal
  • 59,252
  • 17
  • 87
  • 127
0

As this question isn't really related to php but to OOP in general, this answer should be valid for many languages.

There exists different pattern in OOP. I suggest reading about the "gang of four". It's a really nice book that explains some of the most basic pattern that can be used when doing OOP.

Instead of using a class to keep a sets of static function, you should consider storing all of your functions in a namespace.

Classes often define objects (like physical object). Any physical object has a sets of properties and behaviors.

When designing a class, you're trying to define those behaviors and properties. For example, a bag.

class Bag:
    // Methods
    function open: ...
    function close: ...
    function empty: ...
    function add(item): ...
    // Properties
    array items: []
    bool is_open: false

Some properties or method can be hidden or visible to the world. In my example, you could make the function add throw an exception whenever you try to empty or add an object to a closed bag. It's clear that all of the methods here are related to the actual object.

Adding methods or attribute that are unrelated to the bag should belong in a different namespace or class. It really depends on what you're trying to do.

Loïc Faure-Lacroix
  • 13,220
  • 6
  • 67
  • 99