I was recently hired in a company and I have been asked to help writing an API that was left unfinished. I do not have much experience yet so I am never too sure what are good coding practices.

This API will be used later to create an web interface showing information about the application developed by the company. Both the application and the API are written in PHP.

The API is basically a single file with a big list of functions (around 300). Each function calls another function in the application. For every function the same pattern is applied :

  • It creates the object containing the function it wants to call.
  • It calls the function from this new object and store its result.
  • It returns the result.

The object itself is never returned or referenced. It seems really weird to have to create an object and destroy it every time you want to do something. It makes the object oriented design completely useless.

I then looked into the code of the application. To summarize, the architecture is done this way :

  • There is one big class "Database" that connects to the database, and does quite a lot of other stuff.

  • There are a lot of other classes (around 40) that are children of Database. They basically process data and create SQL queries to communicate with the database. Each of those classes are related to a subject, for example there is the class "Score" that provides functions to get or update score from some or all users. But none of those classes have attributes (except those from Database), they are just used to communicate with the database.

I now understand the logic behind this weird API design. Since these classes are only used as communication tools, you could just create the object to call a function and it would work.

So my questions are :

  • How bad is it to create an object just to call a function?

  • If it is bad, should I redesign just the API or both the application and API? And how?

  • What benefits do you think you will get by redesigning? Is it worth the trouble, or do the costs exceed the benefits? Commented Nov 2, 2017 at 17:32
  • How bad is it to create an object just to call a function? -- For what it's worth, the system that I worked with at my last job did exactly this. It was designed this way to make it very flexible and configurable. We ultimately replaced it with a new system, because each object (which retrieved a single datum) cost one call to the database, and we were able to get significant efficiency gains by combining those operations and taking the database cost only once. Commented Nov 2, 2017 at 17:35
  • I was afraid this was very bad practice so you reassured me. Even though it's probably not optimal for the performance it's true it allows more flexibility. Thanks for sharing this !
    – Kalaeman
    Commented Nov 2, 2017 at 20:34
  • I didn't say it was bad practice; I don't have enough information about your specific use case to make that determination. I merely said that it didn't work out in our specific case; not because of the objects, but because of all the database calls. What I don't quite understand about your system is why they didn't simply use higher-order functions. See phptherightway.com/pages/Functional-Programming.html Commented Nov 2, 2017 at 20:55
  • How in my system would higher-order functions be useful?
    – Kalaeman
    Commented Nov 8, 2017 at 14:29

1 Answer 1


Don't overflow the heap and you should be fine. If you obeyed the principle that constructors should not do real work then object creation is about as expensive as pointer addition.

Even if it wasn't, worrying about it is likely premature optimization. If you must speculate, speculate that code is fast but hard for humans to read until proven otherwise. In over 20 years the only good performance optimizations I made without hard data were the kind big O notation teaches you. This isn't one of those.

Now that isn't to say there isn't an issue here. What you're looking at is objects being used as functions. This isn't tragic but it's not a helpful design. If you're looking at code like

$result = new Employee()->getIDBySSN($ssn);

then you might as well be looking at

$result = Employee::getIDBySSN($ssn);

Because you're just as concretely bound to one implementation of getIDBySSN(). Maybe you don't care about that. If you don't then everything is fine. If you're thinking the static method looks better, maybe because it's more familiar, well then fine. I don't think it's any better. What I think is better is this:

$result = $employee->getIDBySNN($ssn);

Why? Because now I don't know exactly which implementation I'm using. That means other implementations can be substituted in here. It also means you have to do more work because now something else (preferably another class) has to figure out which implementation to use here and hand that to you.

This is called separating construction from behavior. It's very powerful. It will preserve the ability to use polymorphism. But it's not cheap. It's up to you if it's worth caring about. The best rule of thumb for if this is OK I've found is how stable the concrete thing is that your binding yourself to. I've never regretted using String or basic library collections this way. However, other things, especially from my own code base, have made me wish I had a time machine so I could go back and yell at myself.

Other than that, no, I make nameless temporary objects (the fancy term for this) all the time. It's just part of the cost of doing business.

  • If $result = $employee->getIDBySNN($ssn); requires you to do more work then why is it better? Commented Nov 2, 2017 at 21:47
  • @immibis Because now I don't know which implementation I'm using. I work hard not to know things. Things I know about cause me to need to change when they change. Things I don't know about can't hurt me. Commented Nov 2, 2017 at 22:51
  • Which changes are you thinking of? Your version means if you want to change Employee::getIDBySSN($ssn) to Building::getIDBySSN($ssn) for example then you won't need to change more than one place. However that is not an example of a reasonable change so it's clearly not the one you are thinking of. Commented Nov 2, 2017 at 22:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.