Answer the question
In order to leave comments, you need to log in
Answer the question
In order to leave comments, you need to log in
Karoch, I advise one book, but I immediately warn you, it is sooo complicated and you won’t read it in the subway or in the toilet if you want to learn the material. I even want to say more, some people could not master it ... well, the book is called "Stop sitting on the toaster and asking questions! Go and write fucking code"
PS now different people will come and start advising different Fowlers, Design Patterns, Elementary Templates design, McConnell, Martin ... certainly these are good books, but without the experience of industrial programming it's all so ... from the evil one, that is, there will be some increase in knowledge, but still it's not that ... (but it's still worth reading, but McConnell, it would be nice to re-read it)
PPS get a job
Designing an application is not only a complex, non-obvious process, but it is also not done according to books. It is done by experience.
The second fact that should not be forgotten is that the architecture is written for the application, i.e. as long as you have two classes and one view, you don't need an architecture. And in the process of growth of the application, experience will be gained, weaknesses will be revealed, so on and so forth. As a result, after 2-3 more or less serious applications, you will be able to form for yourself the main features of a good architecture.
IMHO:
1. Interfaces can be used wherever you want. Interfaces should be used where it is planned to expand / replace modules, etc.
2. An abstract class differs only in that it cannot be created. Do you need it like this? You are making a regular class, at some point you need to expand it into different classes? You make it abstract, cut the heirs, raise the compilability.
3. Other OOP where you don't like your own code =)
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question