Forgot your password?
typodupeerror

Comment: Re:What we need... (Score 2) 129

by Jason Smith (#40214961) Attached to: Book Review: Elemental Design Patterns

God yes. One of the early examples I saw of this was a Hello World that ran to a couple thousand lines of code, using every conceivable design pattern at once. It was horrendous.

Engineering is trade-offs, in almost every case. Adding an abstraction to encapsulate a bit of complexity doesn't dodge the fact that under that abstraction you are *adding complexity*. Sometimes the complexity is necessary, and sometimes it is a kludge. Knowing the difference requires understanding what the various underlying concepts you are adding actually mean, how they interact, and what they cost you in terms of implementation or design flexibility given your implementation language, constraints, etc.

The EDPs are a way of conveying that information about the underpinnings of the current design patterns literature, so that the huge amount of information at our fingertips gets new utility... and hopefully so rising programmers can have a smoother introduction to the literature than we did.

Comment: Re:Thats what I have been waiting for. (Score 1) 129

by Jason Smith (#40214921) Attached to: Book Review: Elemental Design Patterns

I see that as one very useful direction, absolutely. Frankly, this isn't that different than what we do now, in turning a set of concepts of programming (such as data types, functions, and so on) into bits.

The EDPs form a bridge between the higher-level abstractions of the existing design patterns literature, and language constructs. From there, it's turtles all the way down. :)

Comment: Re:The biggest problem with design patterns... (Score 2) 129

by Jason Smith (#40214847) Attached to: Book Review: Elemental Design Patterns

*Absolutely*. To me, one of the biggest wins of design patterns is that they let me quickly solve, describe, or *avoid* problems that others have solved, described, and found ways around.

In fact, the material for the book came from my research in creating a system for the automated detection of design patterns in source code. It was originally intended to find the patterns to help document the system, but it quickly became obvious that the biggest benefit was that it defined the sections of the system that *didn't* need documentation. Other people had already done so. Instead, it let the developers concentrate on the portions of their code that were unique to their implementation. i.e., their innovation.

I find patterns to be incredibly useful, obviously, but they are often most useful not for what they define, but what they *don't*. The negative space of the system, once it is seen as a system of patterns, is where the real fun starts.

Comment: Re:Patterns over hyped? (Score 2) 129

by Jason Smith (#40214771) Attached to: Book Review: Elemental Design Patterns

I think you understand design patterns better than most people, to be honest. Copying and pasting a design pattern is the worst way of going about it, IMO. The bit that most people seem to miss, is that if it's not what you need, alter it to suit your purpose.

That was actually a main reason for writing this book - to try and provide folks with an easier ramp-up to the existing design patterns literature in a way that got across the point that these patterns are both a) composed of smaller pieces that are understandable, and b) made to be custom-tailored.

It's not the structure of a design pattern that is important, it's the concepts that it embodies. Fulfill those concepts in a way particular to your language, problem, or system, and you're still using that pattern, even if it doesn't look much like the example source provided.

Of course, it really isn't obvious that that's the case when we haven't had a good underlying taxonomy for those concepts... hence the book.

Comment: Re:Patterns over hyped? (Score 2) 129

by Jason Smith (#40214735) Attached to: Book Review: Elemental Design Patterns

"Unfortunately the Gang of Four book was written partly as a pattern reference, so it's not so easy going as a tutorial for those without either a CS degree or 10+ years programming experience."

Exactly. In my experience as an educator, I've seen both undergraduate and graduate students struggle with the GoF book when handed it with only the edict "Thou shalt do this." What inevitably happens is that they start copying and pasting the sample implementations as rote mantras, instead of seeing the underlying concepts as mutable pieces that they can work with to create a solution that fits what *they* need.

That's where the EDPs come in. They give a ground level set of concepts and taxonomy to start composing the more abstract notions in the GoF text. For those new to patterns, they give an introductory way of approaching the literature, and thinking about even the most basic concepts of programming independent of implementation details. For folks who have been using patterns for years, they give (perhaps) a new way of looking at the tools to give them new uses.

The design patterns literature is full of an immense amount of good information... when it's used well. When it's just copied and pasted, it can easily lead to worse problems.

Comment: Re:The biggest problem with design patterns... (Score 2) 129

by Jason Smith (#40214689) Attached to: Book Review: Elemental Design Patterns

I completely agree. In fact, in the book I show where some languages, such as C#, have started implementing some of these EDPs as basic primitives. I also show how these ideas are implemented in a number of languages (Java, C++, C#, Obj-C, Python, even straight C in a couple of cases) to demonstrate how the language feature set can radically change how you choose to implement a concept.

Ultimately, that's what design patterns are: concepts. How they get implemented is unique to a language, a problem domain, and a set of constraints and requirements you're working with.

Change the language expressibility, and you change how you can approach the concepts.

Announcements

+ - If you had one last lecture to give...

Submitted by Jason Smith
Jason Smith (3310) writes "Randy Pausch, a VR researcher at CMU known best for co-founding the Entertainment Technology Center, and being the creator of the Alice programming environment, did. He's been diagnosed with terminal pancreatic cancer, and has just a few months to live. This is his last lecture: "Really Achieving Your Childhood Dreams". I watched the webcast live on Tuesday, and... I couldn't look away. http://www.etc.cmu.edu/global_news/?q=node/42 It's almost two hours, all told, but worth every second spent. (I just noticed that it is, ironically, number 42. How appropriate.)"

Your mode of life will be changed to EBCDIC.

Working...