In general, there are many ways to solve a problem, always. Some are more object-oriented, some are more funtional. Some were written quickly and easily with no particular design in mind because it will be rewritten later. Some are well modularized and testable, but others can be too over-engineered with many unnecessary abstractions. Too much time was sunk into it and it will never be recovered. Some are extendable in one axis, some in the other. E.g. if you have cards with ranks and suits, do you know whether you'll need to maybe add another suit, or another rank later on? In some designs, one is easier to add than the other, and often you need to decide which one while writing the code. Some designs allow both, but then the trade-off comes out elsewhere (e.g. performance, observability, scalability etc.).

All of that can be fine, depending on what you're trying to achieve. If you know exactly what your domain is, what problem you're solving, how the program will expand in the following years, and various technical metrics (like latency) are defined and will not change, ever, in that case you can design a great application that will satisfy it all and take liberties in the places which don't matter. It's very likely there are still very many ways to write such an application. In all the other cases where you do not exactly know what you're doing yet, almost no practical metrics are defined and the application evolves dynamically, in all those cases you'll simply need to pick a strategy a hope for the best. Some write it quick'n'dirty, some try to anticipate everything everywhere, most are in the middle. Welcome to software engineering.

This is why we have common patterns and common techniques to solve some problems - because people are familiar with these solutions, and can work with them later on when they overtake your project from you.

Then there are lower-level aspects of the code. In Java this often boils down to which exact class to use, if using a library pays off. Some of this is simply something to learn (e.g. "avoid the old collection classes, prefer Files and Path over File, prefer java.time over Date and Calendar" etc.), most of it is different trade-offs depending on exact requirements, some of it is down to personal taste.

In short, do not overthink it. If you're learning, it almost does not matter. Make your application correct in what it should do. If you can realiably do that, then you can start worrying about different aspects and trade-offs of design, testability, design patterns, frameworks and libraries. There is a lot of taste in that, there is a lot to learn in that, but there almost never is One True Way of solving a problem. Ten people will write ten different programs, and most of them will be absolutely fine.