In OOP there is a certain amount of theory and good practice in writing classes and interfaces.
They are inside folders with consecrated nomenclatures. The class name must be identical to the file name. The class must be preceded by the package command that matches the class structure of the class itself.
But there seems to be no theory about how objects should be written and architected.
Is that right? Do you like the programmer?
They are inside folders with consecrated nomenclatures. The class name must be identical to the file name.
No, object-oriented programming has nothing to do with it, and does not preach anything like that. It is a myth that you must have read somewhere written by someone who does not understand the subject, or misinterpreted something.
The class must be preceded by the package command that matches the folder structure of the class itself.
Maybe you're talking about Java, but that's technology specific.
But there seems to be no theory about how objects should be written and architected.
Is that right? Do you like the programmer?
It's not like the programmer, it's need. The programmer must understand the problem as a whole and put together what is needed the way it is needed. And this is only possible with much experience. That is only acquired by making mistakes, doing several projects, participating in teams with well-trained people (which is rare), seeing the mistakes of others and improving their understanding. You always have to be open-minded to see new things. Which is a bit problematic nowadays because people want everything fast, skip steps and do not get the necessary foundation to think for themselves. Then she looks for magic formulas to look like she's doing it right.
It has a lot of confusion of concepts in the question. Objects are not written, classes are written . Architecture is something much broader than this.
Objects must be instantiated where they are needed, not before, and obviously never after. I hope you understand what you're talking about, otherwise turn some houses on the board to learn those concepts first. Do not use names of things that do not know what it is. Knowledge contradicts a well-understood concept each time and never jumps to a concept that requires the understanding of its dependencies.
