Emergent Component Method

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

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". --DafyddRees

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

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

This page mirrored in ComponentDesignPatterns as of April 29, 2006