OOP and all that: Quiet, to yourself

I try not to argue about the advantages / disadvantages of the PLO or the procedural approach, no matter where.

You want - consider the program as a set of functions. Do you want - as many objects. If you want to - get stuck at all aspects. And then there is Comrade Shalyto and his finite automata. The case is master's.

It is important to understand that paradigms arose for a reason. The appearance of OOP is caused, not least of all, by the enlargement of programs and the increasing complexity of their architecture. Now they often talk about AOP, which makes the end-to-end functionality into a separate entity, which can greatly save a person’s efforts.
')
Also, it is very important to clearly define the objectives of your program - it depends on it which paradigm will work. If you care about extensibility - well, apparently you will have to get acquainted with the PLO. If speed is a procedural approach. It is important to avoid fanatical obsession with one paradigm .

After determining, in any case, do not forget about refactoring (here Martin Fowler jumps out, and shouts - Smell your code! Determine the smells!). Most refactoring is in OOP, but functions can also be refactored.

Further - more: I recall the patterns, which are the sample methods of circumventing the pressing problems of the language and solving architectural problems. Where patterns are, there are GOF and Fowler with POEAA . Then TDD pops up, with its writing tests before writing the code. Further - even more, there will be mountains of incomprehensible abbreviations and forest and methodologies.

A lot has been written, written and will be written on such topics.

But no silver bullet.