Am I defining classes in OOP correctly?

Question

PHP

Guys, OOP has already begun to move into me. There are two issues that concern me.
1. Is it convenient to write small applications in the OOP style when it is programmed by one programmer? Or OOP is made mainly for team development.
2. Can I control the number of OOP style DB requests in a team? For example, I need no more than 5 requests when generating the whole site, while I don’t know what other coders of this project are doing. With the help of OOP, can this process be tracked, or will each class access the database in its own way?
3. Whether I correctly understood the essence of self-written CMS. Page class (header, footer content), product showcase class, product class, navigation menu class, breadcrumbs class.

Answer 1

1) Certainly convenient. It is even more convenient to use frameworks that (all) use OOP
2) You can use a singleton (singleton template) and already control the number of requests in it. However, here I can be a little wrong (because it's hard to find out where the request came from: from messages or from loading the page)
3) it's better to use MVC in self-written cms. There is already a division into models (product, breadcrumbs), views (page, showcase, menu) and controllers that connect it.
Answered all two questions ;-)

Answer 2

1. Is it convenient to write small applications in the OOP style when it is programmed by one programmer? Or OOP is made mainly for team development.

OOP is handy when your application has more than 3 lines of code.
2. You can.

3. Whether I correctly understood the essence of self-written CMS. Page class (header, footer content), product showcase class, product class, navigation menu class, breadcrumbs class.

Wrong. The product deserves a separate class, and everything else is just layout, it does not need entities in the code.

Answer 3

OOP is not a style, it's a paradigm.
It can be used to write programs of almost any size, but is inconvenient for small scripts.
Style is more of a notation, like CamelNotation
OOP is not an implementation of any solution. Almost everything you want - restrictions on access to the database and other things, can be implemented both in OOP and without it. Who cares?
The essence of OOP and functional programming is only in how to arrange pieces of code - by functions or by methods. But the access restriction is connected neither with the function nor with the method, but with how you implemented this restriction.
The main idea of ​​OOP is this:
There is data. We encapsulate them in a class.
There are methods that manipulate exactly this data. Therefore, the methods must also be in the data class.
If we have to add data, change its type and format, in the case of OOP, we can easily edit the methods that are in the same class. We can write new methods, we can remake old ones, we can combine them. In the case of functional programming, the cost of reworking the program will be much more expensive and more confusing.

Answer 4

OOP is designed to structure code so that new features are introduced with little effort and allows you to write less code. The product class has, for example, price and availability - this class will be the parent of all products. We expand the "product" class longer, create several children: "photo equipment", "telephones", etc. We take the class "photographic equipment" and create children that symbolize manufacturers (here you can immediately enter their website and any data besides). Next, we expand the manufacturer's class according to its models - here we fill in the remaining parameters. Now, in order to add any other product from the created groups, you only need to extend the class of the last parent, respectively, there is much less code to write. Well, this is purely for understanding why and why