Proper project design in Java
Good time of day !
I want to learn how to design my applications correctly. To make the code readable for other programmers. I know that there are design patterns, but I don't know how to use them.
I want you to help me understand how I can better design this task:
There is a class that converts an XML file and returns
List<>with this data.There is a class that does image manipulation (in the method parameter, the path to the file is taken from XML), and this method should return n-th number of images (there are a lot of them), since I crop one large one several times. Is it possible to make some method in this class to create factory images?
And a class that writes these images to the database.
There is an idea to implement streams (Threads) at the time of dividing the image into parts and writing them to the database.
What patterns are they more suitable for my task? And explain to the newcomer how you, the professionals, choose them? The code is already written, but I would call it bad code. I want to learn how to do everything right! Thanks for understanding.
2 answers
The topic of the applicability of design patterns draws on a very voluminous article or even a book, it is impossible to put all this in the answer on the forum. But, since you asked, here are some tips:
- If you have a poor understanding of design patterns, read Design patterns of Freeman, Sierra, and Bates. This book explains the most common patterns very clearly.
- Read the classic work on this topic - Object-oriented programming techniques design projects. Design patterns of the "Gang of Four". This book is best used as a reference that describes the purpose, scope, implementation details, and benefits of using specific patterns.
- In addition to the classic patterns described in these books, there are patterns that apply in specific areas: enterprise, parallel programming, web development, etc. There are catalogs of patterns in which you can work with them get acquainted.
- Think about whether you need exactly the patterns. There are many techniques for refactoring to make the code cleaner, more beautiful, more readable, and more reliable. You call your code bad-think about why you think so. A lot of repetitive sections-take them out in separate methods. Many
switch/caseor multi-stageif/else- take them to separate classes. The method of a couple of hundred lines-break it down into shorter, more meaningful and complete pieces of work. this can be read in detail in the book Refactoring. Improvement of the existing code of Fowler and company, or briefly-in this cheat sheet. - Think again about whether you need patterns. The main purpose of design patterns is to make the code easily extensible and changeable. Think about whether your application will change, if so, how and in what places. If there are few or no such places, perhaps you are doing overengineering, that is, meaningless complication the code.
- Never think "where should I put the pattern in my program". This approach is a direct way to meaninglessly complicate the code. The correct train of thought is "there is a problem in my program that is well solved with the help of a pattern." To be sure, check the wording of your task with the areas of applicability of the pattern in the pattern catalogs.
Competent application design is a matter of experience. To get this experience, consider your code as critically as possible, look for problems in the design, fix them. Over time, you will begin to clearly see the "roughness" and potential errors, and later-to anticipate them at the design stage.
It is difficult to advise anything more specific within the framework of the answer. If you have specific questions about app design, feel free to ask them. You will certainly be helped if you describe your task in more detail and give your solution.
In my opinion, the goal should not be so much readable code (although this is not a little important and goes hand in hand with the subsequent statement), but more cheap code. By cheap, I mean code that is cheaper to change.
Any application changes over time, new requirements are added, existing requirements change, etc. Programmers have to change the program to meet these changes. The faster and more convenient these changes can be however, the fewer problems and errors it causes , the cheaper they will be. And the cheaper - the more competitive. All these patterns and approaches, etc., IMHO, are just aimed at helping to make the code more cheaper.
Therefore, during the development process, try to evaluate what is obtained on the subject of how you may have to change it later. And the patterns-they just show you examples of how other developers solve various problems (and they are worth getting to know), but they will not give you a panacea for all the troubles.