Others on Patterns

Besides not having time to write (and using lazy excuses) I also often find myself on both sides of the fence. And so here I'll just let others speak for me, in the form of a Twitter conversation from November 2010. (Imagine me having that conversation with myself…)

@coreyhaines: Thinking about discussion last night regarding whether we should teach patterns to beginners. Hmm… I took the 'no' stance
@agilecoach: @coreyhaines Why? Patterns represent some basics. Wish I learned from them 1st rather than the “subclass for reuse” nonsense
@RonJeffries: @agilecoach i'd start with “remove duplication”, and “express ideas”. all else seems to flow from there. cc @coreyhaines
@coreyhaines:My thoughts exactly RT @RonJeffries:i'd start with “remove duplication” & “express ideas”. all else seems to flow from there
@coreyhaines: stmt: patterns are a language to describe categories of never-reached refactoring destinations based on the rules of simple design. discuss.
@coreyhaines: Thought: why do we need to 'teach' patterns at all? What do we gain from doing that these days?
@coreyhaines: When was the last time you actually used a pattern explicitly? Today, are patterns a bandaid for too much design-up-front hijinks?
@coreyhaines: Good start for learning the 4 rules of simple design: http://... Simple statements, deep and subtle consequences.
@coreyhaines: Why 'refactor towards a pattern' when you can simply refactor, let the rules of simple design guide you.
@coreyhaines: Question: Can you really do TDD without the 4 rules of simple design?
@jasongorman: … The problem with patterns is that too many folk apply them as solutions before the relevant problems have occurred :)
@marick: @coreyhaines I refactored toward strategy last month. It didn't hurt to realize, half-way through, where I was going.
@coreyhaines: @marick did it help, though? could have you reached it with simply rigorous (and vigorous) application of the 4 rules?
@coreyhaines: @jasongorman exactly. and that is what I'm wondering about. problem caused by the importance we tend to place on 'learning' them?
@KevlinHenney: @coreyhaines You can't design by bullet points. Instead, you build on experience, understanding and communication. That's patterns.
@unclebobmartin: @coreyhaines I think if it more as a progression. Quantum Mechanics→Classical Mechanics→Chemistry. 4-rules→SOLID→Patterns.
@unclebobmartin: @coreyhaines There are patterns because of the principles. There are principles because of the 4 _postulates_ of simple design.
@coreyhaines: @KevlinHenney I'm talking about design patterns explicitly, though. They seem to be bullet points to design to.
@coreyhaines: @unclebobmartin I agree with that progression. Why do we stress patterns over 4 rules, though?
@unclebobmartin: @coreyhaines Dont refactor _to_ a pattern. Refactor using the knowledge _of_ patterns. Use patterns names as you get close to them.
@unclebobmartin: @coreyhaines The fact that I know patterns means that I can give names and shapes to the probability space of the code as I refactor it.
@coreyhaines: @unclebobmartin do you need a knowledge of patterns to refactor effectively? I think the 4 rules are enough. Patterns come much later.
@coreyhaines: @unclebobmartin always after the fact, though, in by-the-book TDD, is my postulate! :)
@unclebobmartin: You do not need to know the patterns in order to refactor. You _do_ need to know the patterns to refactor well. Travel broadens the mind.
@coreyhaines: .@unclebobmartin wondering about an intense (refresher) workshop on explicitly applying the 4 rules. or is that just #coderetreat :)
@KevlinHenney: @coreyhaines That's not design patterns. Design patterns offer awareness & a dialectic for reasoning/communicating about what you're doing.
@coreyhaines: .@unclebobmartin knowing the patterns leads to refactoring well OR refactoring well leads to knowing the patterns?
@coreyhaines: .@KevlinHenney that's what they are meant for. It seems like they too often are used as design building blocks.
@marick: @coreyhaines 'Cause sometimes you're not smart enough to work always from first principles?
@marick: @coreyhaines Knew a guy in college who insisted on reproving all lemmas he used, even Pyth. theorem. Slowed him down *a lot*.
@marick: @coreyhaines Not claiming parallel cases by any means, but even Jove nods and having a reasonably safe way to go autopilot helps humans.
@coreyhaines: .@KevlinHenney as evidenced by a lot of the input from people in this discussion.
@coreyhaines: And here are some thoughts on the 4 rules by @jbrains http://...
@coreyhaines: @marick those are good points. The initial thought was that we teach DP way too soon to people with poor results.
@marick: @coreyhaines I bet I reached the end point faster than I would have, had I never heard of Strategy.
@coreyhaines: @marick I wonder if you did. Or if you ended up going too far?
@DocOnDev: @coreyhaines … I know I've refactored well when I reach a pattern. Knowing makes my design no better or worse. Done is done.
@coreyhaines: @DocOnDev does reaching a pattern say you've refactored well, or does it say you've added more than you need to?
@marick: @coreyhaines Perhaps. If I did, I bet it's in the noise - not significant compared to all the other mistakes time and change will reveal.
@KevlinHenney: @coreyhaines Agreed. The surface versus the whole, some see only the former where others see the latter. Same for the four rules.
@coreyhaines: @marick is it a result of your higher-level of experience, though?
@coreyhaines: And here is a short (11-minute) video of @jbrains talking about applying the 4 rules in a specific case: http://...
@DocOnDev: @coreyhaines I spend more time cleaning than creating these days. Results can differ when you are pruning away rather than leaving out.
@coreyhaines: @DocOnDev how come? Is there an inherent difference that makes the 4 rules less fundamental? Most of my coding is cleaning, even new stuff.
@DocOnDev: @coreyhaines Are you suggesting patterns are too heavy? I actively avoid applying them, but acknowledge a certain bias.
@coreyhaines: And, of course, read the c2 wiki on the 4 rules of simple design: http://...
@tottinge: @coreyhaines technically or practically? 4 rules guide the Refactor step (at least) and it is spotty without an approximation thereof.
@DocOnDev: @coreyhaines No… I don't think so. I think my approach differs when cleaning up big hairy messes. Maybe I need to look at why that is.
@coreyhaines: @DocOnDev definitely think about it.Please do share your thoughts with me after you have.This has begun to weigh on my mind
@coreyhaines: @tottinge practically. My thought is that we would do ourselves well by refocusing and intensely studying the 4 rules.
@coreyhaines: Lots to do now- blog: 'why a journeyman tour?' & 'stop focusing on design patterns' screencast: applying 4 rules to this http://...
@ecomba: @coreyhaines When we first start teaching we should teach how to grow things, later we will teach common problems already solved (1/2)
@ecomba: @coreyhaines So I would say we should not teach patterns to start with, but show them at a later stage as common solutions to problems.(2/2)
@coreyhaines:perhaps a course on design patterns:'Meta-analysis of the results of effective applications of the 4 rules of simple design.'
@ecomba: @coreyhaines Now that sounds like a good idea :) You could also call it “Refactoring to patte….” Hang on… ;)
@unclebobmartin: @coreyhaines #coderetreat 4 postulates would be a good emphasis for certain targetted code retreats.
@unclebobmartin: @coreyhaines Knowing patterns leads to refactoring well. More knowledge and context is always better. Think globally act locally.
@coreyhaines: @unclebobmartin As I've facilitated more and more of them, I'm starting to emphasize them beyond most other things.
@unclebobmartin: @coreyhaines It would be interesting to empahsize patterns or principles at a #coderetreat.
@coreyhaines: @unclebobmartin Is the (small?) benefit of knowing them offset by the danger of misunderstanding them for beginners?
@coreyhaines: Serious thanks to everyone for sharing your thoughts and ideas. I'm off to dinner, though; I was supposed to go before I started this. :)
@tottinge: @coreyhaines agreed. They are a very concise formulation of many rules and observations.

And then it went on somewhat longer, but this pretty much sums up all my opinions on the topic.

stray_words/others_on_patterns.txt · Last modified: 2012.01.31 13:01 by infinitary