If I understand your broken English correctly, you read the famous "Design Patterns" by Gamma, Helm, Johnson & Vlissides, but you don't find the described design patterns useful for your designs, so you doubt your skills at object oriented software design.
There can be two main reasons:

1) The design patterns you learnt are really not usefully applicable to your projects.
The GoF book lists a selection of design patterns (other designs can be equally good); some of them are motivated by specific C++ or Smalltalk features and are irrelevant simply because you use Java; and the described design patterns are simple and pure specimens selected from a continuum of good designs.
The didactic style of "Design Patterns" cannot emphasize how the listed creational patterns must be necessarily combined in comprehensive designs of object lifecycle, or how defining and implementing interfaces "buys" arbitrary and synergistic composition of many structural patterns.

2) You don't really understand specific design patterns, possibly because you are unwilling to bend them to meet reality, and/or you analyze your requirements in a way that doesn't allow object oriented design.
Breaking requirements into the smallest possible pieces isn't necessarily useful; you should design by inventing classes, deciding how they should interact and behave, and how they are expected to collectively implement the requirements.
During design and coding phases, you can decide at any time that you need some design patterns: you can add a visitor because a complex data structure needs to be processed in full; you can decide that some classes are similar enough to get a common interface and some of composite, null object, proxy, etc.; you can decide that there are complex subsystems that can be kept in line with a façade or bridge; and countless other ways to improve your design (not to implement requirements) through the introduction and modification of design patterns.