5

In my efforts to rewrite a past project of mine with OOP in mind, I have broken my code up into classes such as Devices, Facilities, etc.

Before moving to a more object oriented approach, I just stuck all of my helper functions in an included "functions.php" file. Using Devices as an example, would it be best to have a Devices class for my object specific properties/methods, then have a DeviceManager class to store functions like getDeviceByName, getDeviceByID, etc?

From what I am understanding, OOP is more about readability/manageability than anything else, why I assume the purpose would just be to have something like DeviceManager::GetDevice("Computer1") in place of GetDeviceByName("Computer1")

2
  • 3
    If you are using static methods within your classes, then they are no different from simply namespaced functions. Then again, that's not OOP. Commented Jan 18, 2014 at 13:49
  • Yes, you can actually just need to define a few namespace for those functions. But either way, you need to group similar functions into the same namespace or the same class rather than put everything in one file :) Commented Jan 18, 2014 at 14:05

4 Answers 4

3

In a OOP languages like C# or Java, you simply can't have functions outside a class, so there's no issue. That doesn't mean you're doing OOP, which is a mindset.

In PHP you can either put the relevant functions into a nampespace or within a class (inside a namespace). It's up to you, there's no right or wrong approach. Personally, I'd put them into a class because that's how I'm doing it in C# and it'll help a bit with productivity: I group related functionality in one place (class). It's easier to manage.

But strictly from a programming point of view, there's no difference, your code won't be cleaner/decoupled or more OOP because you've put functions into a class or namespace

Sign up to request clarification or add additional context in comments.

Comments

3

If you are thinking of using a class as a namespace then you can just as well use an actual namespace:

namespace MyCollectionOfFunctions; function printMyName($name) { echo $name; } 

And then you can use the functions like this:

use MyCollectionOfFunctions as fn; echo fn\printMyName('Brett Powell'); 

There is nothing wrong with functions. Do not let anyone tell you that they belong is a class, as static methods. It can be done that way, but since we got namespaces there really is no reason for it.

Comments

1

A few advantages when using Namespace or Class for static functions.

  1. Namespace and Class Name helps distinguish functions. You can avoid naming conflicts.

  2. DPDate::FirstDayOfMonth() is better than FirstDayOfMonth() when you want to take advantage of auto suggestion of the IDE.

  3. It is really all about cohesion and decoupling.

3 Comments

Why a class over namespaces?
You can use namespaces too. I agree.
Well, static methods should only be in a class if they are related to that class. The DateTime::createFromFormat method is an excellent example.
-2

You must following this rules:

  1. In OOP you MUST ALWAYS use a CLASS
  2. Your method must have a single responsability
  3. Avoid generic helper classes, classes must have a simple and specific responsability
  4. Don't use static methods, use strategy (pass the object throw the param) to call a method, this way you can create a Mock to test your methods.
  5. Avoid private methods, this make dificult to test your classes

Keep this things in mind, and you will gona make a clean code. =)


Answering Eric about item 4: This code it will use static method:

public function myFunction() { $deviceId = DeviceManger::getDeviceId('computer 1'); // Rest of code using the device id } 

This way i cant mock the return of Device ID, this way i can:

public function myFunction(deviceManger) { $deviceId = deviceManager->getDeviceId('computer 1'); // Rest of code using the device id } 

The code with mock in test function:

$deviceManager = $this->getMock('DeviceManager'); $deviceManager->method('getDeviceId')->returnValue(1); myFuncion($deviceManager); 

6 Comments

Can you elaborate on 4? 5 doesn't sound like particularly good advice either
It is helper function. I don't really think he needs to mock anything. It is just input/output function. There is no internal member needs to be mocked. Event the passed parameter can be mocked, isn't it.
Ethan the helper function maybe don't need a mock in it's test, but the method that need the helper will need, like the code I post now.
MikeSW, why are bad rules?
1. No! 2. Ok 3. Highly Debatable 4. See 3 5. NO! Private methods are internal details and they shouldn't be testable in the first place Ther are no rules in OOP and developing in general. There are principles which should be understood and respected, but also adapted to the problem and sometimes even ignored.
|