Is it sure to use mostly static classes?

Question

I am currently rewriting an electronic store, but only the client side, i.e. CMS remains mostly tactful. I do not use a pre-built structure, since the system must maintain backward compatibility with CMS, and I must have complete freedom of the code structure.

The new system is based only on MVC, and I have a Bootstrapper that loads controllers based on the current uri, and the latter use models for real work - both with sessions and with the database.

tl; dr This is my first project without a predefined structure.

I am very inexperienced when it comes to design patterns. I know how most of the popular ones work, but have never used them.

Now I suspect the code smells because all my models are classes that consist solely of static methods. I do not see any advantages in doing them differently. I usually need some methods in different places through the code. That is, I need to get a registered user in the main layout, check the user rights to see the current page in the bootstrapper, and display the user panel with the controller. I would need to re-create the object each time or save the global one if I hadn't used statics. There will also be no need for more than one such class at a time.

Something is missing me, because although I use OOP, some of my classes are just meaningless containers for their methods (and sometimes a couple of private variables). I could just use PHP4 and simple functions.

Any comments or recommendations would be highly appreciated.

EDIT: Despite all these educated answers, I remain unconvinced. Despite the fact that, most likely, due to my lack of experience, I still do not foresee that something is wrong with the current setting. I mean, I don’t even understand the situation when I would have inconvenience due to the code architecture, as it is now. I hope I don’t get a harsh lesson when it’s too late to change anything ...

Answer 1

You are right, this is the smell of code, and everyone will tell you this baaaad.

Therefore, I suggest more likely to do a self-assessment of the severity of the problem:

• Do you have classes with many getter and setter ?

• Are your static functions similar to the ones below?

  If so, try moving the logic to the MyClass class, which will already be more than OO. This is a classic mistake from a procedural / scripted world.

---

  static void myMethod( MyClass anObject ) { // get value from anObject // do some business logic // set value of anObject } 

---

• Do you have a lot of global status , for example, data obtained from the current session?

  If yes, make an assessment if you want to change it. The OO method was to transfer a session along a chain of calls. But in practice, it’s convenient to access the session as a global object. But this interferes with testability. Try to remove some global state and turn it into a regular object that you pass and manipulate in methods.

Make this assessment and try to define utility classes, services, and business objects. . A utility class is helper classes using utility methods (e.g. formatting, conversion, etc.) that can be static. The service class implements some business logic, but they must be inactive and one instance is enough. Business objects user , products , article , etc. - This is the place where you should focus your efforts. Try turning simple data into objects with embedding some kind of behavior.

See if the entity is dumb . Even if it is for Java, the concepts are common.

EDIT

Here is my analysis based on your comment:

• You do not have a domain model with entities. You directly manage the database.
• What you call your model is what I call services, and where you execute the business logic that manages the data. Service classes are stateless, which is correct. As you noted in the question, you need to either constantly recreate them, create one global instance, or use static methods.

The OO paradigm will say that you should try to create a domain model in which you will map your database to entities. At least the DAO . As for the hassle-free procedural services, this is actually the reality of many web applications - if you don't need more, you can stick with that.

My 2 cents

Answer 2

If you mainly use only static classes, you really pulled an object out of object-oriented programming. I am not saying that you are doing something wrong, I am saying maybe your system should not borrow OOP. Perhaps this is a simple application that requires some basic functions of the utility (sends email, etc.). In this case, most of your code becomes very procedural.

If you are dealing with databases, you might have a static db class and a simple business layer, and your php application will interact with your business layer, which in turn will interact with your database level. This becomes your typical three-tier architecture (some people like to refer to it as 4 t-iers and share the actual database from the data layer, the same thing).

If you are not actually calling methods that require an object than what is the point of all these static classes, just ask yourself a question.

Answer 3

One thing that you may notice is that if you plan on doing any unit tests with taunting / stubbing, it will probably be difficult for you because static classes and methods are not easy to mock, drown, or test.

Answer 4

I would be wary of using static variables and classes in web applications. If you really have to share the instance between users, then it should be nice to have one template (lookup "Singleton").

However, if you are trying to save state on different pages, you must do this either with the ViewState or with the Session object.

If you had a global static variable, you could have a situation where concurrent users are struggling to update the same value.

Answer 5

Short answer: This is normal, but you do not agree with the benefits of OOP.

One of the reasons for using objects is that most of the time there is more than one type of object that plays a role. For example, you can swap your DBVendor1 data access object with a DBVendor2 data access object that has the same interface. This is especially convenient if you use unit tests and need to replace objects that really work with dummy objects (mocks and stub). Think of your objects with the same interface as Lego bricks with different colors that fit together and are easily interchangeable. And you just can't do it with static objects.

Of course, the increased flexibility of objects comes at a price: initializing objects and combining them is more work (as you wrote) and leads to more code and objects that combine other objects. Here you create creation templates such as builder and factory .

If you want to go this route, I advise you to read the dependency injection and using the DI framework .

Answer 6

Technically there is nothing wrong with that. But in practice, you are losing the many benefits of object-oriented programming. Also write code / functionality where it belongs .. for example:

  user.doSomeTask() 

in a user object makes sense than

  UserUtils.doSomeTask(User user) 

Using the concepts of OOP, you abstract the functionality in which it is included, and in the future it will help you change your code, expanding functionality is easier than using static methods.

Answer 7

There are advantages to using static methods. One of them is that since you cannot inherit them, they work better. But using them all the time limits you. The whole OOP paradigm is based on the reuse of base classes for the careful use of inheritance.