Last Build Date: Fri, 8 Oct 2010 14:29:15 -0400Copyright: Copyright 2010
Tue, 23 Mar 2004 00:06:29 -0500Went to another NoFluffJustStuff symposium this weekend. Got to chat with Dave Thomas (amongst others). I asked Dave in particular what his thoughts were with respect to the following observation/question:
Mon, 22 Mar 2004 23:36:29 -0500Yes, I know the first bit is common knowledge, just bear with me.
Wed, 11 Feb 2004 18:36:26 -0500The answer my friend, is Abstract Data Types. Some smart folks looked around and thought "Hey, it seems like I am always making lists of things. It doesn't matter what things I am dealing with, or what language I am writing in, I am always making lists of things that I want to add to, delete from, and iterate over. I could talk about this "List" idea as an abstract concept, defined only by the operations it supports". Once this realization was made, the next step could be taken. Abstract Data Types allowed designers to talk about their design at a higher level than lines of code, without ever talking about implementation. This was a Good Thing. And to get there we used the same trick, abstracting operation from data, but in a slightly different way. In fact, the Standard Template Library in C++ did exactly what we did before, abstracted away the operation from the data and parameterized the data type. Abstract Data Types are good, but they don't give us the catalog of known good bridge designs that we were after. They give us the equivalent of standardized materials and fasteners. Engineering certainly benefits from standardized materials and fasteners, but what do we need to do to take the next step? As you may have guessed, I believe that the next step is the use of Design Patterns. At this point, we need to define what we mean by a Design Pattern. I will use the one that the GoF used, which is "A pattern is a proven [abstract] solution to a problem in a context". The word "proven" is important as it implies that this way of doing things has been peer-reviewed and has passed muster in all situations that it's been analyzed. The "solution to a problem" bit is important because it keeps us on point, and reminds us that this stuff isn't all theory, we are trying to get work done. The "in a context" part is important because the pattern doesn't exist in a vacuum. One of the benefits to using standard patterns is that of rapid comprehension, when you say "I am using Pattern A" your audience makes some assumptions about how and why you are using Pattern A. Those assumptions figure prominently in the rapid communication of your architecture and intent, and they are also the context that this pattern exists in. To illustrate, imagine that you have a message on your answering machine from a friend that says "come over to my place and bring a screwdriver". There are a set of assumptions you might make as to what your friend needs help with. You might bring over a goodly amount of reference material involving the torsional analysis of the screwdriver. Upon arrival at your friend's place you find him holding a paint can. Now, let's assume that you are not very bright. Your friend might have to explain to you what he wants you to do with the screwdriver, and why. Now, you *can*, of course, pry up the lid of the paint can with the screwdriver, but you lose a couple things when you do - all the analysis of the screwdriver that's been done is lose, since it assumes you will be turning something, and the ability to rapidly communicate the job to be done is lost, for the same reason. You are using the tool outside its context. So it is with Design Patterns that we realize the goal of having a set of "known good" designs. Using these designs in your software architecture gives you a couple main benefits, as shown in the above "screwdriver" story, namely: *The ability to quickly communicate design and intent *The ability to take advantage of time-tested, peer-reviewed techniques. Patterns aren't the answer to all of Software Engineering's woes. We still have to work hard to write bug-free, easily maintainable code. The current hype (that appears to wax and wane) that surrounds Design Patterns could lead to conditions that dilute or even eliminate one of its main benefits. If you end up calling *everything* a pattern, which is easy to do since the definition must, of necessity, be broad and vague, then the term loses its meaning. I could start refer[...]
Thu, 16 Oct 2003 00:02:12 -0400To talk about the motivation for and role of design patterns in software engineering, let's take a look at how a "traditional" engineer and a software engineer might do their work. A community determines a need for a bridge. The community retains the services of a civil engineer. The engineer will confer with the community to get some requirements such as the expected average and maximum load to be supported and maybe some fiscal limitations, as well as the inteded location for the bridge. The engineer might then go to the intended location for the bridge and gather some requirements from there such as length and depth of the gap to span and the characteristics of the substrate to anchor to. Then the engineer might consult a catalog of known good bridge designs and evaluate each one with respect to the set of requirements, eventually using some judgement to determine a good bridge design. At this point, it's all implementation. Compare this to what a Software Engineer might do. A client determines a need for a software system. The client retains the services of a software engineer. The engineer will confer with the client to get some requirements such as the functional requirements and expected load as well as the intended environment for the system. There will be additional non-functional requirements such as latency and fiscal issues. The engineer then goes off and - what? Designs the system. Typically there is only personal experience and maybe anecdotal evidence to assist in determining the best design. There is no catalog of known good designs. There are methodologies that try to assist you in making sure you've thought of all the typical things. But by and large it's a black art at this point. And this is a Bad Thing. It's a bad thing because software is controlling more and more critical systems. We have software assisting in delivery of radiation doses into patients, the movement of planes and trains and rockets, the timing of traffic signals. We can't afford sloppy engineering. Can you imagine if bridges would randomly collapse and, when asked about this phenomenon the engineer would respond "yeah, I dunno, sometimes they just do that". We wouldn't tolerate that, but for some reason we think it's ok that software behaves that way. We can't afford to let this behahvior continue - ask the Italian Space Agency. Due to a numeric type overflow the Ariane 5 blew up 30 some odd seconds after launch. Because of a bad design in the software system a rocket, a satellite, and for a while the reputation of the ISA went up in smoke. There are many such examples. So, how do we fix this? To answer that, let's look at what we've done so far. I would like to present a brief history of software engineering from the dawn of time until now, hitting highlights carefully selected to make my point. In the beginning we flipped switches and watched light bulbs, and that was good. But the novelty soon wore off, and even after we came up with clever ways to persist our switch settings onto paper or magnetic media we realized that interacting with the computer at this level was highly inefficient. At some point some smart folk said "Hey, I am always keying in the same set of 32 1's and 0's to add numbers - well, almost thhe same - the only thing that changes is the numbers to add. Why don't I write 1's and 0's to take English-looking words (like "ADD") representing operations and the data they operate on as input and output the appropriate 1's and 0's. And voila, assembler language was born. This was a Good Thing. It was good for two reasons. Error prevention and detection and moving closer to the problem space. If you have to key in 32 1's and 0's to add two numbers, the odds of you flipping a bit somewhere are fairly good. And if you do, the odds of you noticing are not good. Errors are easy to make and hard to spot. If you get to write "ADD 1, 1" the odds of you misspelling "ADD" or keying in the wrong number are[...]
Sun, 1 Jun 2003 19:07:12 -0400As seen by a low-level peon.