DesignSignatures is a phrase I saw for the first time in the text "Java Beans Developer's Reference" by Daniel Brookshier, New Riders 1997.

I believe he uses it to mean something more like a protocol or set of rules to which classes must adhere in order to take part in a framework.  It's interesting because they are just rules which are not enforced by a compiler, such as by type checking.  Classes do not even inherit from the framework.  In fact, such classes which adhere to these design signatures are in no way distinguishable from non-participating classes based on their definition alone.  The only identification of these classes (Java Beans in this case) occurs in the jar file manifest!  The classes participate in a development tool environment when in the context of their utilization their definition is examined and interpreted by the tool using class Introspection, a feature in Java where you can examine meta-class information.

From the text:

"Although Design Patterns could be applied here, the goal is to not describe a principal of design, rather it is a set of design rules that can be used by another program to understand a developer's original intent."

-----
"classes must adhere in order to take part in a framework"  sounds a bit like TrygveReenskaug's RoleModeling, which I have been studying lately.  Role modeling only captures the communication rules, where Design Signatures might, from your description, also include inheritance regulations.  I like role modeling at the outset, but have not chased it down into code.

Bottom up thumbnail on RoleModeling: take an interaction diagram or event trace for a particular situation.  Flatten the vertical axis so timing information is lost, only the list of messages is left.  The lines connecting the objects are what I call "channels" (Trygve doesn't call them anything).  The resulting picture, retaining the list of messages, is one fragment of a RoleModel.  Take all scenarios related to a use case.  Smash them all together in the same way.  You now have one role model.  

Top down thumbnail: take an aspect of your design.  Split the class into the different conversation's it will be in.  Create a role model for each conversation (i.e., list all the collaborators and messages in that conversation).  Now you need tool assistance.  You can merge roles together to produce your classes.  Normally, at this point, when you look at a class, you cannot see the different roles it is playing.  You have lost that information and simply cannot recover it easily.  Will a role-modeling tool, you can unpack any one role out of a class, since the messages stayed tagged with their role models.  You can apply the role model to another class.  I am just starting to work with these things.  It looks promising, but definitely needs a tool.  (Could EnvyDeveloper be used to do this?)


AlistairCockburn
----
The ObjectExplorer has a feature called contracts that shows you all the messages sent to an instance variable. I've found it useful for reverse engineering roles, which I can then use to forward engineer imposters.
--KentBeck

-----

I've just finished reading the book "Presenting Java Beans" by Michael Morrison (Sams.net) and found that he refers to DesignSignatures as DesignPatterns!  I found that misuse (or redefinition) of the term to be so annoying that I ended up getting too frustrated to read the pages that mentioned it!  Does anyone know what the "official" JavaSoft terminology is?  If it's DesignPatterns than we should start lobbying someone to change it to something more meaningful (like DesignSignatures).

KyleBrown
-------------------------------
The original Java Beans documentation (white paper) from Sun uses the phrase DesignPatterns.

Java in a Nutshell 2nd Edition (probably the most popular Java 1.1 reference out) mis-uses the phrase DesignPatterns when talking about Java Beans.

Yes, it's sad. Too bad Gosling and Arnold's Java Programming Language book (cousin to K&R's The C Programming Language book) isn't more widely read.  Aside from being an excellent reference for the language (JDK 1.02 -- pre-Bean), Gosling seems to know what design patterns are. He directly references the GangOfFour book.  

Considering that the Java Bean spec doesn't reference the GangOfFour book, I wonder if any of it's authors had ever heard about GOF DesignPatterns? (I ask this only half-jokingly).

--- ToddCoram