Hello forum members!

I program in Java for about six months (and in general, I’m probably programming the same amount), before that I’ve touched on C # a little bit.

I started the study with: "Learning Java" from O REILLY, then read Bruce Ekkel's "Java Philosophy" (which was hard for me). Then I tried myself in mobile development, studying the book from O`REILLY "Programming for Android". But the problem is that literature gives a technical understanding of the language, meaning what is a class, what is a variable, a collection. This literature does not give a clear understanding of how I should design my classes, which class contains such fields, such as how to make the structure of classes beautiful, so that the whole program does not consist of one class of 3000 flows.

For example, take the decomposition of the game of checkers. How to design this program properly? In my understanding, there should be a class Deck, a class of checkers with an arbitrary name, a class Player. But how to make these classes a whole? How to improve the relationship between objects, how to encapsulate logic to get rid of duplicate code.

Now you should not mention design patterns. Because if there is a pattern, it doesn’t mean that we have to poke it everywhere, anywhere. I would like to create the proper program architecture myself.

So I would like to know, and how did you learn to design your program architecture?

Closed due to the fact that it is necessary to reformulate the question so that you can give an objectively correct answer to the participants of Kromster , Grundy , Abyx , Nofate ♦ 7 Sep '16 at 12:33 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • 2
    Practice. Unit tests. Reading someone else's code. - enzo
  • It would be extremely interesting to hear the answer to this question from more experienced participants. From myself I can say the following: through trial and error, you understand how to act in this or that case. I will also support @enzo that reading someone else's code can help in understanding how to write. It remains a trifle to find someone else's code from which you can take good practice ... - Bald
  • "Clean code" read? - rjhdby
  • 2
    By the way, yes. I also recommend clean code . it is still possible to look at the perfect code - Bald
  • 3
    Only practice. There is no theoretical approach to get everything right at once. Write code. Write tests. To see that some places turn out to be inconvenient to implement, and some classes are difficult to test. Think about how to reallocate class duties and refactor. Check the principles of SOLID (without fanaticism). To repeat. After a while it will get better. - Nofate ♦

1 answer 1

First you need to decide on priorities (without sorting. 1 point is not more important than the others)

  1. Choose a paradigm / technology. A lot of them. At the hearing MVP, Reactive, functional style, etc.
  2. Understand what will happen to the code after the release of the application - released and forgotten or constant development.
  3. How many people will be involved in the project. If one sting, then this one, if a big team - is quite another.

Then get a large notebook (A4 just right) and draw a high-level block diagram of your application (lifehack pencil and eraser they rule). Then for each block its own small scheme with implementation details. Then burn to hell and start over. Change paradigm / technology, if necessary. Repeat 5 times.

  • 2
    "Then burn to hell and start again", or development by the method of extreme programming xD - Ksenia
  • 2
    "UPD Put in the comments, that in the priorities to add, I will update the answer." - In such cases, it is customary to make the answer "general" in order not to farm the reputation at someone else's expense. - Kromster
  • @Kromster and in thoughts was not. :) - rjhdby