0

I'm working on a large PHP project, alone, and for years I did a lot of procedural programming, but now I'm trying to switch over to OOP, since I feel like it's finally matured enough in PHP and my knowledge of it isn't as poor. In my class methods I was considering returning in a consistent way that can be used in both PHP code and also be sent out over JSON API. I've tried to search for this, but either I'm doing it completely wrong and no one else thought of an idea this terrible or I just am not searching the proper way.

So in general I'm curious if there is a way to have consistent returns that are easily workable in both code and to send back out over APIs.

What I have in mind is:

public function doThing($stuff) {
    $result = new stdClass();
    $result->success = False;

    if ($stuff == 'not correct') {
       $result->error = 'Not correct, guy.';
       return $result;
    }

    $result->success = True;
    return $result;
}

So then it's a matter of 

$check = $Class->doThing($otherstuff);

if ($check->success == True) {
   do whatever is true
} else {
   do whatever is false, show/return $check->error
}

And with JSON it's as simple as:

echo json_encode($check);

So on the client library you just have to do the same success check and error display. And of course I can add in other things to return as well, such as results from a database query or what have you.

Is this correct? Would it be normal/not a bad thing to do this for many of the common methods? Potential benefits I considered would be to insert ACL right into the method if I needed to or anything else, so I wouldn't have to do all of the error checking prior to the method being called.

I feel like perhaps I'm being too verbose and there's a better way.

max_
  • 24,076
  • 39
  • 122
  • 211
simontemplar
  • 885
  • 1
  • 10
  • 17
  • I am not really sure what your question actually is. But from what I see, it looks to me like you want a method to always return something. In OOP there is this concept of "command query separation". Method should either alter objects state or return information. I would actually recommend you to try going through [this list](http://stackoverflow.com/a/16356866/727208) of materials (don't let the title scare you, 90% of it is actually pure OOP-related lectures). – tereško Jan 10 '14 at 06:07
  • I'm asking whether or not the approach I demonstrated is a valid way to approach methods in large projects where the same methods are used both through the software also for things like REST. Thank you for the information, though, I will definitely look into it. – simontemplar Jan 10 '14 at 06:15
  • The quick answer would be: no. But probably not for the reasons, that you suspect. If you are really working on a large project, then you should try to separate the interface (visual or REST) from the application logic. Classes that deal with business logic should not have any clue about how the information will be presented. And the other issue is that, as it is now, you are not really using OOP. It's more of a "transitional form" between procedural and OOP code. You should take advantage of fact that object can hold a state. – tereško Jan 10 '14 at 07:52

0 Answers0