Design Shield is something you put in to hide what you are doing, to give you protection, something to hide behind to give you room to change your mind, perhaps. Also discussed in Shield Pattern. Opposite of Design Shield is looking for a name, see Design Burp.
Design shields come in different sizes, strengths, or weights. A heavier, bigger, stronger one adds flexibility but costs your design in cognitive complexity. Kent Beck told me they talk about a bag of design or coding ideas, and you want to take the things at the top of the bag. If you have to reach wayyy down into the bag and mess with 'become:', then you are at some level of desperation. Paul Dyson comments in Make It Fast Breaks Make It Right on people overusing patterns and getting very flexible code, but at high complexity. I could wish Kent or Ron would write a starter list of what's at the top of the bag, and what is below, and so on down to the bottom.
We need a name for a shield that is not provided by the programmer's design, but by the language - Language Shield!? One could then describe the history of programming language as one of Design Shields becoming Language Shields. Gee, am I looking forward to those fully pattern oriented languages! :-) --Falk Bruegmann
You are asking the the language designer to put some special design shields in for you? What, in particular? --Alistair Cockburn
In fact, I was not thinking about any particular shields. I guess I was not very clear on just what I was thinking...
You can be shielded against certain types of change by certain features of a programming language. You might call such a feature a Language Shield. If these are not provided, and you still need to keep the cost of change down, you have to provide equivalent Design Shields instead.
Machine language does not provide many Language Shields (although it provides some, when compared to setting switches on ENIAC :-). Assembly language, procedural languages, object-oriented languages... Each one puts some shield features into the language that had to be provided by design before.
Maybe patterns are "just" the kind of Design Shield that is evolving today. They have already influenced the design of some languages (e.g. Java). So if you extrapolate the trend, it leads to the prediction that some patterns that are Design Shields will migrate into programming language to become Language Shields in the future (will Java be called "hybrid-pattern oriented" some day?!). This was what I was driving at. Of course, it's just a guess.
Hope this is not too crazy. Doesn't matter... it's fun :-)
BTW, maybe Shield Pattern seems so hard to "nail down" at first just because a lot of shields already reside in the language, not in the design as with most patterns. --Falk Bruegmann
One classic example of a Design Pattern being subsumed into a language feature is the Iterator pattern which is very useful in C++ and Java but just not required in the, dare I say, more advanced Smalltalk. It is interesting that the feature of Smalltalk that makes Iterators redundant, Blocks, is nothing to do with iteration per se. Its not even anything to do with collections. Having said all of this, I'm not sure if Iterator is a Design Shield, or Block a Language Shield :-) -- Stephen Hutchinson
Wiki places mentioning a design shield or Design Burp.
The several pages discussing Java interface-implementation question
Many of the Design Patterns, especially Bridge and Facade, of course.
Template Method/Hook Method are the quintessential OO design shield form
The observer family of patterns including the bigger ones like Reactor and Multi Caster
Interfaces Should Be Adjectives also has the counter argument
I question whether Hungarian Notation and Interfaces Should Be Adjectives are Design Burp(s). It seems to depend on how they are used and what your perspective is.
Hungarian Notation has been called a burp because it tells you about the internals of a variable. Is that true? Actually, it tells you about the type of a variable, that is, it is a statement of its external behavior. It could be considered a burp if the type tells you more than you need to know in a particular context. The fact that classes and types are pretty much synonymous in many languages further clouds this.
Interfaces Should Be Adjectives seems more clear cut to me. Within the context of Extreme Programming (which is one strong basis for Dont Distinguish Between Classes And Interfaces) adjectival names are burps. This is pretty much because you chose to make a noun-based concrete class name in the beginning. If, on the other hand, you chose to start with some statements of partial behavior (Cloneable, Serializable, Elliptically Formed, Renderable, Connectable, Graphical) and use factories to create the instances, the shield is intact. This is definitely not your everyday programming, and I am still suspicious of it, but to me it does make the burp categorization contextual.
Are you inferring that a Design Burp is a bad thing? I think the name gives that impression, but the page itself implies it is neutral. It says a burp is something that gives out information, and then adds "hopefully something you want them to know". So whether Hungarian Notation is a burp is independent of whether the type tells you too much.
The same probably applies to Design Shield. Sometimes the author of a class hides too much of the implementation, so that there isn't enough information to use or reuse it. Then a shield becomes a bad thing. (I'm think here of 3rd party software, not the XP context.) Lack of documentation is a Design Shield in that it hides the intent of the author - often bad. Other shields are good. -- Dave Harris
I agree the name has a bad connotation. But with a burp you get some idea of the person's innards, so there is a kind of graphic exposure there. Hungarian Notation explicitly chooses to expose the innards of a design element, and so is the exact opposite of a Design Shield, which conceals the innards, or, alternatively, provides a place behind which the designer can hide and reshuffle. I guess I do think revealing the innards are generally a bad idea, hence the name. I recall when C started doing type checking, and I had to declare that the parameter was a pointer to a pointer to a structure. I never managed to get comfortable with that much exposure of other parts of the system. Alternate name suggestions are of course welcome, since naming is not my forte. --Alistair Cockburn
I think I did react a bit emotionally to use of 'burp' (I apologize) but that aside, I do really wonder about this internals vs. externals thing. If we use m_ppnCounter (pointer to a pointer to an int) then where are the insides? What is the inside of an int? If we have m_ppmcThing where mc is my class, it is a shield (except in the case of Black Box Componentry) because the innards of my class can change radically over time. The behavior is exposed, it is just a matter of whether it is documented in the code.
To me, it seems that there are a variety of levels at which the principle of shielding can operate. At some levels the hiding and reshuffling has to do with source code dependency: what else do I have to change when I change this? Hungarian Notation is an example of one of these. At the design level it seems that classes themselves are shields, since we expect them to change type over time.
I suspect that Interfaces Should Be Adjectives is a shield as well because it allows you to pass in reference to only the part of an object that makes sense in a context. In Java, it specifically allows you to be independent of the hierarchy concerns that are imposed by the single inheritance model. -- Michael Feathers
...(recovering from lost append) pointer to a pointer to an int is terribly fragile. suppose I add or subtract one pointer to that (pn or pppn). All sorts of things are hanging on this, and I have to go and find them all and change them all. The point of a class is that it hides / shields/ protects the client. If the ppnCounter were instead a pointer to a Fuzzball object, then it's the Fuzzball's personal business whether there is another pointer involved or not. Should Fuzzball get changed to add or remove a level of pointerness, the client's don't all have to be edited to add or remove a 'p' to a variable name that shouldn't be worrying about it in the first place. The Fuzzball class definition acts as a Design Shield, protecting the client's programmer from the Fuzzball's programmer, and giving the Fuzzball's programmer some implementation latitude. The ppnCounter, on the other hand, forces the client's programmer to know what the Fuzzball's programmer has eaten for lunch, as it were, to get back to burps, and gets the two really closely bound. not much space for movement. ppn reveals the insides because it is saying, there is a thing1 I know of, and I also know it knows of a thing2, and I know that thing1 knows that thing2 is an integer. You have the objects there, just without clothes on. --Alistair Cockburn
See original on c2.com 