0

When using Object-Oriented programming in PHP is there a simple rule of thumb on what should be made into an object or should you try to make the entire program using object-oriented code. I know this is quite opinion based but I can't seem to find any resources that could answer it for me.

Thanks.

3 Answers3

2

I would suggest to read general oop concepts to get grip on that: http://oopsconcepts.blogspot.de/

What an object should be is largely language independent and whether your function should be an object or not fully depends on the context in what it is used.

Trivial code is usually not improved by making it object oriented.

In a scenario where your function is injected into something and must be replaceable it might make sense to make an object that implements an interface out of it.

Samuel
  • 6,126
  • 35
  • 70
0

Objects (or rather classes) should relate to a specific noun. For example, you might have a class called User, or Product. Functions generally are verbs. So you might have something like Product->Update().

Simple having a collection of unrelated functions in a generic Class does not constitute good OOP design. If the function is simply doing as you've advised, then it shouldn't have its own class.

BenM
  • 52,573
  • 26
  • 113
  • 168
-1

A fairly standard pattern to follow with the kind of trivial, but global function your are discussing is to add it to a Utilty class.

In principle that is simply a class with public static member methods, that would normally be grouped by relation - exactly as you would a file of functions.

class MyFileUtility
{
  public static function FileToArray($filePath) { // do stuff }
  public static function ArrayToFile($array, $filePath { //do stuff }

  ...
}

$array = MyFileUtility::FileToArray('somefile');

Now you will use the methods of the Utility exactly as you would a function, but they are in a class, if it makes you feel better.

There are a couple of benefits:

  1. Auto-loading will work, so long as you have configured it.
  2. IMO You will generally be in a better / safer namespace situation.
  3. If you like typing "::" You are well in :)

_____________ Edit _________________

Here is an explanation of a static Utility class added for clarity.

http://en.wikipedia.org/wiki/Utility_pattern

Gavin
  • 2,153
  • 2
  • 25
  • 35
  • 1
    A rule of thumb in OO-PHP I'd suggest is actually _avoid `static` whenever possible_ :) – Elias Van Ootegem Dec 20 '13 at 12:29
  • I would suggest that stateless static is of no consequence, in fact not different to a function but name-spaced better. I do agree though, start adding state and you can introduce very hard to find issues and testing difficulties with static data. So to clarify, in my world a Utility class is stateless. – Gavin Dec 20 '13 at 12:56
  • PHP is, essentially, stateless. In between requests, it looses all state. Static method calls imply overhead, and are slower than just the old-school `require 'functions.php'; and call global functions. What you're doing (a stateless class with constant methods) is wrapping a class around global functions (ie globals in drag). Why bother writing `Utility::` and not just write the function name? – Elias Van Ootegem Dec 20 '13 at 13:08
  • So that autoload functions, and no jungles of include statements are required, and to ease code insight in the IDE and as a very simple mechanism to avoid naming collisions. For the same reason as any object oriented vs procedural debate, because the tiny loss of performance is worth the gain in productivity. Opinion of course, but this is how we work, and we work very well. – Gavin Dec 20 '13 at 13:14
  • On the flip side, we do also have a global_functions.inc file which contains the most common short hand functions used in the system. SO I would certainly agree with the suggestion that typing Utility:: can get tedious and pointless fast. Overall I think it will come down to the organisation of the system at hand, and the use case for those particular functions / methods. – Gavin Dec 20 '13 at 13:20
  • 1
    -1 Static methods are not part of OOP paradigm and introduce tight coupling within the codebase. Basically, what you recommend is **bad practice**. Please go and learn about OOP, before starting to give "advice". – tereško Dec 20 '13 at 17:38
  • @tereško What I suggested is nothing of the sort. It is the procedural function scoped to a class it implies no state and no coupling beyond the use of any function in global scope, and is not an object, it is class scope. Perhaps you should re read my answer. You are entitled to your opinion of course. But the comment above is entirely wrong and the down vote unjust. – Gavin Dec 20 '13 at 20:18
  • @Gavin: _"It is the procedural function scoped to a class"_, don't you see the contradiction in that statement? Translating procedural style functions into OOP paradigms is not understanding what a programming paradigm is. OOP requires a different approach to the way you code/think about the problems, juts like functional programming doesn't translate to procedural. Using OO means thinking OO. Using procedural constructs, but sprinkle them with class scoping is like polishing turds. (Not that procedural code == crap, but you get the point) – Elias Van Ootegem Dec 22 '13 at 12:22
  • @EliasVanOotegem I understand your position, I am not confused about object oriented programming, I have not suggested that this is object oriented programming and the question has not asked for an object oriented solution, rather, "should I?" My suggestion in fact implies don't use an object, but if you have a need to organise your procedural global functions that is what a Utility class is used for. This is not object oriented advice, and was never intended to be. I still see no detriment and only benefits between well organised static utility classes (not singleton) and global functions. – Gavin Dec 22 '13 at 13:10
  • Happy to agree to a difference of opinion, and I guess this question has been held for inciting opinion, thank you for your input @EliasVanOotegem. The indication that I should learn about OOP before giving advice, on the basis of a religious view against "static" is a bit much. I infer tereško you would suggest using an object at all times. And further that static is always bad? Or you didn't actually read my answer or the question. I work in the real world where over engineering is **bad practice**, and static Utilities with no state are a viable, safe, productivity aid. I am not alone. – Gavin Dec 22 '13 at 15:22
  • @Gavin: I absolutely, 100% agree with the statement that _over-engineering is bad practice_, which in my case manifests itself as a deep rooted hatred and dismay of everything Java :), yes, in real life, a static is often used, I try not to, but with deadlines looming, I can't honestly say I've never done so. Yet, using those `static`'s is often accompanied with a `TODO` comment in my case like `//todo: Rethink RootNS\Parser\DOM services` as I still see them as admitting bad design, or oversight. Such static classes are often a bin of functionality you overlooked at the start of the project – Elias Van Ootegem Dec 22 '13 at 17:10
  • @EliasVanOotegem Having recently seen a Utility class, called of all things "Utility" covered in a mass of random non related functionality, reading like the prosecutions case against the underlying framework, I would have to say that rings true :) – Gavin Dec 22 '13 at 17:45