|
Just came home from a live event where a Canadian gentleman was playing with his rhythm group.
It was ultimate!
Felt like I was on cloud number nine!
No matter how many times I see him performing it always gets better and better.
|
|
|
|
|
You didn't get his name or his group's name?
|
|
|
|
|
Marc Clifton wrote: You didn't get his name or his group's name?
Shhh....it's a secret.
|
|
|
|
|
In that noise? No chance. He did mention the guitarist's name a few times though. Keith something...
|
|
|
|
|
I dont rate Bieber that highly.
|
|
|
|
|
Seen him quite a lot. It always feels like I'm back in the Summer, sometime just before 1970.
This space for rent
|
|
|
|
|
Yep, the same guy. For some reason he's just like wine, gets better every year...
|
|
|
|
|
How to limit code bloat from patterns? You want to read a connection string from your file, but you end up with two interfaces, two concrete implementations, one template, and one native driver dependency? If we make a plan and put our money and resources together, couldn't we just forbid patterns, and lock up Martin Fowler?
|
|
|
|
|
KISS - patterns are useful but not always practical.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
Maybe you will like Anti-Patterns better
|
|
|
|
|
This is what I hate about patterns: because it worked in "Situation A", it's easy to assume it will work in "Situation B"; and with a bit of hammering on the sharp corners, it does. So it starts to be seen as a "universal solution" and forced to work for "Situation C", and D, and ... even when it patently is ridiculous because it works. Very shortly, it becomes a "software religion" and any criticism of it is tantamount to heresy in the eyes of the faithful. A bit like owning a new iPhone ...
This isn't specific to patterns, or even new: if you have a big enough hammer, everything looks like a nail.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If you have a big enough hammer, everything IS a nail.
|
|
|
|
|
ventureaaron wrote: If you have a big enough hammer, everything IS a nail.
My new response in design meetings, from now on! Where would you like your case of beer shipped?
vuolsi così colà dove si puote
ciò che si vuole, e più non dimandare
--The answer to Minos and any question of "Why are we doing it this way?"
|
|
|
|
|
Keep it. Sounds like you may need it for your design meetings.
|
|
|
|
|
|
Cue Michael Jackson.
Software Zen: delete this;
|
|
|
|
|
Don't add anything that doesn't add value; and no, the fact that a pattern exist does not mean it must be applied in every situation.
Any extra code adds complexity and hence costs. Keep it to a minimum.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
Patterns were created as compensation for a language (Java) that cripples you from doing things intelligently. Then patterns were used to compensate for stupid programmers so they could at least write intelligent boiler plate code. But that mostly fails. Then patterns were glommed onto by the likes of Microsoft in their Enterprise.Patterns fiasco, and you know how dead and ancient that is.
So, here's the mantra for 2018: throw out your old patterns and simply do what you know is right.
|
|
|
|
|
Switch to C++. The C++ community doesn't do patterns to any significant extent.
|
|
|
|
|
Why stop with Martin Fowler? Why not lock up the whole Gang of Four, in separate prisons, for the rest of their natural lives.
I use patterns when they are appropriate, but I've never spent much time deciding which pattern to apply to a given situation. This is not at all the same as avoidance of wheel reinvention. Whenever possible, I assemble new projects from existing tested library routines and modules. Some of these may happen to implement a pattern, but I'm not slavish about that. For example, I have several C# class libraries that contain classes that implement the Singleton pattern, but they are special cases that truly merit such treatment.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Tomaž Štih wrote: lock up Martin Fowler?
yes
|
|
|
|
|
I am sorry but patterns are extremely important. Everything must be a pattern.
For instance, if you do not use repository pattern, you are horrible at writing data access. While we are at it, as developer you make sure that your code can seamlessly work with at least MSSQL, MySQL, Oracle, MongoDB, that one little file as DB on the RaspberryPI device and of course flying broom. Never miss the flying broom.
I am not serious. Or am I?
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Around 1982 we obtained a very early C++ compiler (not yet released) that compiled to plain C, which could be used as input to any K&R C compiler to generate binary code. As senior students, we eagerly read this intermediate C code to see how subclasses and inheritance and abstract classes and initializers and whaterver other OO concept was implemented.
At summer time, I was an intern with a company making both computers and software for it, and I got insight in a fullscale, commercial OS, written in a low level language (more or less a set of macros on top of the assembly language) in the early 1970s. To my surprise I found lots of source code in the OS that very much resembled the C code created by the C++ compiler. Lots of OO concepts had been realized by hand coding in a near-assembly language. When I pointed this out to the OS developers, they gave me a blank stare: OO was a completely unknown concept to them. They had all the good reasons for coding it the way they did, using the same arguments as the OO guys, in a somewhat different vocabulary. So I learned that OO concepts came neither with C++, Simula or Smalltalk - they just formalized a language syntax for concepts that had been in use for years.
Patters are similar. I met them after a number of years as a software developer, and my reaction was "Yes? Sure that is good way of structuring the code; we have always done it that way..." Of course there were rule thumpers who where nitpicking some details that diverged from some academic description of a given pattern. In a couple of cases, the details could easily be adjusted to make those guys happy; it never changed the real pattern.
Just like the OS guys did OO programming without knowing it, lots of developers use code patterns "by instinct", without ever looking up its index in some academic dissertation. They use it without being tied on hands and feet to a set of academic absolutes, but adapt the basic principles to a real world production environment. Which is how it ought to be, in my opinion.
|
|
|
|
|
Nice Story...
It reflects my own experience. After some years of Basic, Pascal, C Programming I started to read GOF and about patterns. I realized that I "found" a lot of them for myself while I was coding.
So code with no standard patterns seems not possible to me. You use them - even if you don't know... And there aren't that many you will use every day.
So for the developers in my team I have a simple rule: If you are aware of a pattern - Name the Code/variable/function etc. accordingly. It's great for communication between developers.
-> Don't: Here is my creator for the Storages...
-> Do: Here is my factory for the repositories...
|
|
|
|