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?