Create object just to call a function in PHP. Is it as bad as I think ? How to redesign?

Question

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?

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.