'''Goal''': Create leveraged visual components while delivering production user interfaces.

'''Method''': Hand craft screens with minimal regard for program structure. Refactor code (and screens) so that components emerge through an established progression of language structures. Accept that not all possible components will fully emerge.

'''Example''': Swing Beans can emerge as follows:

	1. Start with code in which adjacent lines instantiate related user-interface components.
	2. Add code to create a panel and change the adjacent lines of code to place the user-interface components into the panel.
	3. Move the code that constructs the panel and its contents into a private method.
	4. Encapsulate the panel and its contents as an inner class.
	5. Move the inner class to a public class (a bean).
	6. Add parameters to further customize the bean.  


'''Note''': A working screen is available for use at every step in the progression. As with any refactoring based method, design decisions are delayed so as to absorb maximal working experience. 

'''Note''': The Swing/Java Bean API is particularly amenable to this technique since it offers structural models for each step in the progression.  Refactoring from one step to the next feels like following a well-worn path rather than repeated acts of invention.

-----
Interesting. Can you provide an example?
-----

'''Q:''' What is a "leveraged visual component"?  And what makes a "production user interface" different from any other user interface?.

'''A:''' Leverage means that it solves more issues than it creates (i.e. useful). Production means to be used as opposed to just evaluated.


'''Q:''' It seems that the goal of this pattern is a description of the process rather than the end result. 

'''A:''' Yes, that is why it is called a ''method''.

'''Q:''' What is "an established progression of language structures".

'''A:''' A sequence, as in the example. One doesn't have to search for a next step, it is already established.

------------

Hmmm. . . while interesting, I'm not sure where this belongs.  It seems like one person's strategy for building a GUI who's using Java Swing, but I can't see it working with other programming environments or applications. For now unless someone can justify different, I'm removing it from the ComponentDesignPatterns list, since I'm working on housecleaning and haven't seen activity on this one since January 2000.  Author: feel free to take a shot at making this into a pattern and get back to me.  PhilipEskelin

In case you're wondering, Ward wrote this. See the page "WardCunningham". 
----

Yes, I wrote it. And it was one person's strategy. I was documenting an approach KaiYu showed me and that resonated with things I'd done years ago in Smalltalk. -- WardCunningham

----
Personally I would find this page more leveraged err... I mean ''useful'' if the corporate-speak was translated into basic English.  For example, if "leveraged" means "useful", replacing "leveraged" with "useful" in the pattern immediately makes it easier to understand.  In fact, one could remove "useful" altogether; do we ever want to create ''useless'' user interface components?

Here's my attempt:

'''Goal''': Create user interface components while continuously providing a working user interface to end users.

'''Method''': Hand craft screens with minimal regard for program structure.  Improve the design of the code that builds screens by applying repeated refactoring steps.  User interface components will emerge as classes. Accept that not all possible components will fully emerge.

'''Example''': Swing Beans can emerge as follows:

	1. Start with code in which adjacent lines instantiate related user-interface components.
	2. Add code to create a panel and change the adjacent lines of code to place the user-interface components into the panel.
	3. Move the code that constructs the panel and its contents into a private method.
	4. Encapsulate the panel and its contents as an inner class.
	5. Move the inner class to a public class (a bean).
	6. Add parameters to further customize the bean.  


'''Note''': A working screen is available for use at every step in the progression. As with any refactoring based method, design decisions are delayed so as to absorb maximal working experience. 

'''Note''': The Swing/Java Bean API is particularly amenable to this technique since it offers structural models for each step in the progression.  Refactoring from one step to the next feels like following a well-worn path rather than repeated acts of invention.

----
Question: Do people who have to work with the MicrosoftWay (VbClassic or DotNet or AspApplication)
can benefit from this ?pattern in a practical sense?. I saw Swing/Java mentioned and stopped reading. PleaseComment in detail if applicable  --DavidLiu