DesignShield 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 ShieldPattern.  Opposite of DesignShield is looking for a name, see DesignBurp.

Design shields come in different sizes, strengths, or weights.  A heavier, bigger, stronger one adds flexibility but costs your design in cognitive complexity.  KentBeck 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.  PaulDyson comments in MakeItFastBreaksMakeItRight 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.
--AlistairCockburn

----

We need a name for a shield that is not provided by the programmer's design, but by the language - LanguageShield!? 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! :-) --FalkBruegmann

''You are asking the the language designer to put some special design shields in for you?  What, in particular?  --AlistairCockburn''

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 LanguageShield. 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 ShieldPattern 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. --FalkBruegmann

''One classic example of a DesignPattern 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 DesignShield, or Block a LanguageShield :-) -- StephenHutchinson''

-----

Wiki places mentioning a design shield or DesignBurp.

'''DesignShield'''
	* ShieldPattern
	* The several pages discussing Java interface-implementation question
		* InterfacesShouldBeAdjectives
		* ExtendToImplementInterfaces
		* DontDistinguishBetweenClassesAndInterfaces
	* Many of the DesignPatterns, especially Bridge and Facade, of course.
	* TemplateMethod/HookMethod are the quintessential OO design shield form 
	* The observer family of patterns including the bigger ones like Reactor and MultiCaster

'''DesignBurp'''
	* HungarianNotation
	* InterfacesShouldBeAdjectives also has the counter argument

-----
I question whether HungarianNotation and InterfacesShouldBeAdjectives are DesignBurp(s).  It seems to depend on how they are used and what your perspective is.

HungarianNotation 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.

InterfacesShouldBeAdjectives seems more clear cut to me.  Within the context of ExtremeProgramming (which is one strong basis for DontDistinguishBetweenClassesAndInterfaces) 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, EllipticallyFormed, 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.

-- MichaelFeathers

''Are you inferring that a DesignBurp 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 HungarianNotation is a burp is independent of whether the type tells you too much.''

''The same probably applies to DesignShield. 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 DesignShield in that it hides the intent of the author - often bad. Other shields are good.''  -- DaveHarris

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.  HungarianNotation explicitly chooses to expose the innards of a design element, and so is the exact opposite of a DesignShield, 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.  --AlistairCockburn
----
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 BlackBoxComponentry) 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?  HungarianNotation 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 InterfacesShouldBeAdjectives 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. -- MichaelFeathers
-----
...(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 DesignShield, 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.   --AlistairCockburn
----
CategoryJargon