41–46 of 46 posts
In my interview revenge fantasy I imagine turning the tables on the interviewer: "Before I tell you what I know about design patterns, let me ask you a question. From speaking with you, I can tell that you are articulate and have a good command of the English language, in other words, you're a good communicator. Now, if I asked you to give me a sentence containing a gerund in a preposition phrase could you? Probably…
Earlier quoted context omitted.
What an obscure load of tosh. I might as well say that all the maths-nerds don't really know how to program because they don't understand design patterns properly, as evidenced by them hating on it all the time. But of course, I wouldn't say that because I have absolutely no evidence and it would be based purely on my close-mindedness and preconceptions. (I also wouldn't say it because I have no hatred towards "maths…
I agree with you in general. But learning the design patterns superficially, and applying them where they don't really fit, can in fact make someone a worse programmer. Hopefully they'll grow out of it, so the "damage" is part of the student phase, but some probably do get stuck there and never progress.
My reasoning is that using a pattern is like documentation. If I see a pattern in some code, i barely have to read the code. Code is hard enough to read as it is, patterns make it easier.
I've heard various figures over the years but one that i think is a decent estimate is that maintenance is 80% of the SDLC. That means reading a crapload of code. Any time you can reduce the burden is a good thing.
It's true that a lot of GoF's design patterns are particular to languages like java and c#, and not relevant to dynamic languages especially.
I think your idea about applying design patterns where they don't fit isn't really the source of the problem. Some developers aren't good at understanding the problem they are faced with, so they do the wrong thing. That isn't anything to do with applying or not applying design patterns - it's a different discussion altogether.
that's as good as saying "i'm sick of arcs, square windows, rafter roofs and linked lists". of course patterns aren't the end-all-be-all of software development. but it's the trait of a good craftsman and engineer to know what patterns exist and how to use them. Sadly, and in that I agree with the author, people in interviews only ask for knowledge of patterns, not when and when not to use them. in that sense, the ti…
> that's as good as saying "i'm sick of arcs, square windows, rafter roofs and linked lists". Well, no -- except for the last, which we'll come back to -- because software isn't the same thing as physical architecture . The nature of software is that components can be and should be reusable, so if you have to rebuild the same thing from a complex "pattern" (more than a simple parameterized constructor or the equivale…
and software isn't the same thing as a design pattern (neither are components). The pattern describes the /concept/ and allows the builders to call an arc "an arc" instead of describing the tedious 100 steps required to actually build one and the explanation of why it works.
Reusability isn't a relevant aspect of design patterns - this is a hallmark of implementation. I can implement 200 singletons and have no need to re-use them. Same goes for windows - just because I have built a bathroom window doesn't mean I need (or even want) to reuse it for my living room.
And language 'quality' is not even a metric, I don't see the relevance of your last paragraph.
I've always taken these "design patterns" to be a Shibboleth of the bottom 80-ish percent of programmers. The mediocrities can't handle math. If they dig deep enough into any technical area, they get confused and insecure and pissed-off. Design patterns is the Revenge of the Not-Nerds. It's to use the language of the business to turn the tables and make the actually competent feel queasy and unsure of themselves in t…
But see, even math can be misused in the same way. Instead of y = sin a * x, it becomes both a functor and a monad. See, that's even more mathematical! Those who have only a superficial understanding can (and will) mis-apply anything. That includes all of us, at some time in our careers. Those you dismiss as the "bottom 80" include anyone starting to learn anything. Some of them will grow to know how to use the tools…
Uncool, bro. Uncool.
Earlier quoted context omitted.
> that's as good as saying "i'm sick of arcs, square windows, rafter roofs and linked lists". Well, no -- except for the last, which we'll come back to -- because software isn't the same thing as physical architecture . The nature of software is that components can be and should be reusable, so if you have to rebuild the same thing from a complex "pattern" (more than a simple parameterized constructor or the equivale…
> software isn't the same thing as physical architecture. and software isn't the same thing as a design pattern (neither are components). The pattern describes the /concept/ and allows the builders to call an arc "an arc" instead of describing the tedious 100 steps required to actually build one and the explanation of why it works. Reusability isn't a relevant aspect of design patterns - this is a hallmark of impleme…
And GOF-style design patterns -- which are heavily implementation-recipe-centered -- aren't the same thing as design patterns more generally.
> The pattern describes the /concept/ and allows the builders to call an arc "an arc" instead of describing the tedious 100 steps required to actually build one and the explanation of why it works.
GOF-style design patterns actually describe the tedious 100 steps required to actually build them, and are in particular selected not by their general applicability but by the fact that they are specifically things that cannot be abstracted in the languages of the time that the book drew from, e.g., they are largely implementation recipes for things for which implementation recipes rather than reusable libraries are required in the common OO languages of the time the book was assembled.
> I can implement 200 singletons and have no need to re-use them.
Yes, but the reusability I'm talking about isn't the individual implementation but the common infrastructure -- with a language that is more flexible than, you can build the infrastructure for a singleton once, and the next time you don't have to build a whole singleton implementation, just the bits that are unique. With physical architecture, you have to build the whole thing each time, so implementation recipes are, to an extent, an unavoidable accompaniment to design patterns, rather than a sign of a problem with the implementation medium (in the case of programming, the particular language.)
That said, if you can write a rant of this length on the topic without once mentioning how they facilitate higher-bandwidth communication between team members, you're missing something.
Asking about design patterns in an interview is not a secret handshake. Instead, you are being tested to see whether you're just bringing your own programming talents in isolation, or whether you're also bringing along the force-multiplier of communication.