What I 'love' about object-oriented programming is that every other year there is a new pattern or paradigm that is shoved down our throats by opinion leaders and self-proclaimed OO-gurus. These architectural patterns all make sense on the surface but by the time people try to apply them in real life and realize that they are mostly a load of horse shit, the instigators have already moved on to the next "big thing". And this pattern is repeated ad infinitum.
The problem is that the pattern that are being discussed ( or a pattern in general, that's far from limited to OO ) are applied by a team of dedicated developer, combing the code meticulously, generally with near-limitless budget.
You read the story about how Linked In, Facebook, LMAX and you dream of applying that.
That won't work. Those companies decided to go with their current infrastructure after their previous one failed miserably and threatened their billion making core business.
Real life for most developer is a lot duller. Very often you will have barely enough to do what need to be done. Consistency, code gardening is difficult to justify a budget for until the house is on fire. No matter how good the pattern you use, the code will be shit if you don't have time to maintain it properly.
The patterns I know of, e.g Gamma/Beck/etc "Design Patterns" are pragmatic and useful solutions to common architectural problems.
And no, they are not "only for languages without first class support for some features", as some think. Or, actually, some of them are, others are useful regardless of language. Heck, a lot of them came from Smalltalk, a language which is expressivity wise miles ahead compared to "modern" languages like Go or Java).
That some people abuse them is not an inherent problem in them. Other people abuse macros, or gotos, or functions (the 100000 line function monstronsity) etc.
