I realized I have a difficulty creating OOP designs. I spent many time deciding if this property is correctly set it to X class.
For example, this is a post which has a few days: https://codereview.stackexchange.com/questions/8041/how-to-improve-my-factory-design
I'm not convinced of my code. So I want to improve my designs, take less time creating it.
How did you learn creating good designs? Some books that you can recommend me?
Designing systems is one of the things that you can only get better at by doing. Of course, it does help a little to read about good design - the recommend general object-oriented design book is the Gang of Four's Design Patterns: Elements of Reusable Object-Oriented Software. There are also other books on design patterns and principles for different types of systems and within different domains.
It's also best to get other people involved. After you create a design, present the problem(s) you are solving and the design to other people for a critical review. Listen to their feedback and have a dialog with them, focusing on why you made the decisions you did. As you are implementing the solution, you'll realize other problems with your design. Make note of these and learn from them. It might also be a good idea to work with other people to review the implementation against the design and requirements as well, and have a critical discussion of the reasons why you have done the things you did.
Although I typically find it best to sit down with other people face-to-face, specific design questions can be asked about here on Programmers. There are also Stack Exchange sites for code reviews and implementation questions.
From the looks of the codereview question you asked, you're at the stage of overdoing it. I think it is a rather common problem among people who discover the importance of good design.
It is actually a natural and probably even necessary step with any skill you pickup. As you start to learn something, the more you advance in the knowledge of a skill and the more you apply it, the better your results and it seems as though you were headed straight for mastery. The problem is, that your new target becomes not the quality of your results, but how much knowledge you have accumulated on your skill.
True mastery of a skill involves the understanding of when to use it and when not to. Overusing that skill is probably the only way to develop such understanding. Sure, you can read about this, but reading is no substitute for experience.
For one thing, reading about design patterns is a bad start IMHO. Reading about OO design principles, such as SOLID and GRASP is better. After getting acquainted to them, study of common design patterns is a good idea, because you will see how those principles can be applied to form concrete idioms.
It is claimed, that when patterns emerge in the use of a language, then the language actually lacks a feature. While this statement is very radical, there is a lot of truth in it. Therefore I would suggest, you look at and play around with other languages to gain a better understanding of the concepts you are seeking to employ, and also to learn about new concepts. A shortlist would be Squeak, Ruby and Lisp.
As for List, my personal recommendation is Structure and Interpretation of Computer Programms, which taught me a great deal about design, by showing me how effortlessly one can create robust solutions to complex problems, with little more than clear abstraction and (de)composition in a top-down manner.
So here's what I suggest:
As others have mentioned, you will only get good with practice and experience. There isn't really that much of a shortcut you can take.
The fact that you look back at your stuff and you don't like what you've written, already puts you ahead of the curve compared many other people in our profession. While you are trying to improve yourself, the rest of us work with people who would write a 500-line function with 20 parameters, all passed in by reference and 15 of them being [in/out] and those people think they are the bomb because they got that mess to work.
When it comes to software design, it's not black and white, either design is good or bad. No matter how much experience you have, you will go back to some of your old code and think, "what was I smoking when I wrote this?" The key is constant evaluation of things and frequently going through the thought exercises to evaluate what makes good code good and bad code bad.
Finally, although nothing replaces practice, it's always a good idea to always keep reading blogs/books/this site because other other people will point out different perspectives that you may not have considered.
To start I would recommend these books:
Up-front design is never as good as out-back design. Just test, code, and refactor. When things are ugly, and you're not sure how to clean it up, then see if some design pattern will help. Practice this for a while and soon other developers will be asking how you come up with such clean designs.
