at the stage of studying the OOP. I noticed the habit of making almost all methods in static classes. On the example of the user class:

Class User
  Public Static Function Auth () {/* Authorization * /}
  Public Static Function Register () {/* Registration * /}
  Public Static Function GetUser () {/* Obtaining a user data array * /}
  Public Static Function Exituser () {/* Deavutorization * /}
  Public Static Function Editavatar () {/* Avatar Change * /}
  Public Static Function EditPassword () {/* Password Change * /}

reasons for this several:

  1. I rewrite the procedural code, there the resulting data go in the form of an array. The getUser method is currently just returning the user data in the form of an array.
  2. Simply no reason to create an User class object only in order to transfer data to the Register conditional method, which will add an entry in the database and put cookies.

And I have a fear that later it can turn it badly. Perhaps I violate 1 of the principles of OOP -encapsulation. I understand, it is better to make it possible to obtain data about the user in the form of an object through the __construct method, and the remaining methods to leave static? In general, we need advice on the correct code architecture.

If there is no reason to create an object -then why create a class at all? To boast that you can do in the OOP? Well, no, you can not.

u_mulder2021-05-07 03:24:10

I know how to make a moment, and proceed, little practice, since you are all in statics))

Jean-Claude2021-05-07 03:24:10

Several strange to have User :: GetUser

teran2021-05-07 03:24:10

@U_mulder, and I said I can do? At the very beginning I wrote that at the stage of studying the OOP and asked the Council on the right architecture, and I do not know how I can in the OOP or not.

Ынвокер2021-05-06 04:19:31

@ Jean-Claude, right, practices are not enough, the goal is just in the study of the OOP, and not just write in any way)

Ынвокер2021-05-06 04:19:51