L
L
larik laravue2021-08-03 23:19:55
OOP
larik laravue, 2021-08-03 23:19:55

What is the disadvantage of using static functions in a project for architecture?

I develop in php (Laravel). It is very convenient for me to create static functions in the model that would retrieve data from the database depending on the input parameters. what is wrong with this approach? in all services where there is a call to the database, I simply call these static methods and get samples.

Answer the question

In order to leave comments, you need to log in

3 answer(s)
M
Maxim, 2021-08-03
@myks92

In general, using statistical functions is not bad, if you understand their purpose and use them correctly in simple things like Helper. But there is no need to turn the whole project into a statistical beast.
Objects encapsulate state and behavior, and an aggregate function doesn't.
What the PHP documentation says about static functions:

Declaring the properties and methods of a class as static allows you to access them without creating an instance of the class. They can also be accessed statically in the instantiated object of the class.

Since static methods are called without creating an instance of the class, the pseudo variable $thisis not available inside static methods. So an important reason you should avoid static methods is that using them loses one of the benefits of objects. Objects are designed to encapsulate data. This prevents unexpected side effects that avoid bugs and improves testing. Static methods do not have data encapsulated and therefore do not benefit from this.
Also, static methods always instantiate an object when the application loads, whether you use the object or not. This increases the load on memory.
With regards to the selection from the database, then at least there will be a dependency on one repository. What if you want to fetch data from Mysql now, and tomorrow from PostgreSQL. In your case, it will be very difficult to move from one repository to another, but if you were using the Repository object, then you would simply write a new implementation and replace it through the DI container.

H
HemulGM, 2021-08-03
@HemulGM

The only bad thing is not knowing when to use which pattern. You do not know.

E
Evgeny Glebov, 2021-08-12
@GLeBaTi

There is no problem if you don't store state/data in a static class.
But you need to look to the future: 1) Transactions
may appear that call several different methods at once and you need to store the connection somewhere (so that you don’t connect in each method). (which is very common) 2) You may need several implementations for each DBMS (which is very rare) 3) ...

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question