Builder Pattern mostly used instead of typical getter/setter boilerplate codes. Gives me a clear idea on properties which are mandatory and optional. Really likes the way it helps a shareholder understand by just reading a couple of lines.
This. One of my greatest fears is will end up suffering from "design patternitis". I've had situations where the first solution I thought was to use some pattern, but later ended up not implementing it due to the impact on both performance or code complexity. Nevertheless, knowing the pattern helped me reach a better solution, so there's that.
I think that if you go the other way around is better. Work your problem, and if in the end the solution ressemble a common pattern then you have a guideline how to implement it.
Your business logic is important, not the patterns.
Yes, I completely agree with you :) I was just talking about my own experience. I usually end up doing what you said, but it is quite common for me to easily recognize a pattern use case before starting any kind of implementation, and hence my fear.
Mixture of Factory for building different objects and Strategy in the context of writing pipeline logic as a means of reducing boilerplate from switch and if statements.
It really depends on the domain. The ones I used the most until now are:
Builder Pattern mostly used instead of typical getter/setter boilerplate codes. Gives me a clear idea on properties which are mandatory and optional. Really likes the way it helps a shareholder understand by just reading a couple of lines.
Just a reminder, "most used" does not mean that they are used correctly, or they are the best solution :D
This. One of my greatest fears is will end up suffering from "design patternitis". I've had situations where the first solution I thought was to use some pattern, but later ended up not implementing it due to the impact on both performance or code complexity. Nevertheless, knowing the pattern helped me reach a better solution, so there's that.
Relevant link: jono.woaf.net/design-patterns/
I think that if you go the other way around is better. Work your problem, and if in the end the solution ressemble a common pattern then you have a guideline how to implement it.
Your business logic is important, not the patterns.
Yes, I completely agree with you :) I was just talking about my own experience. I usually end up doing what you said, but it is quite common for me to easily recognize a pattern use case before starting any kind of implementation, and hence my fear.
Mixture of Factory for building different objects and Strategy in the context of writing pipeline logic as a means of reducing boilerplate from
switchandifstatements.Great mix for "Workflow" like processes.
Components, for custom/aggregate UI elements and factory functions to create them :D
Model–view–controller is an architectural pattern