190 likes | 309 Views
Mimesis and Compositing SWING. Lecture 17, Oct 27 2009. Administrivia. Reminders: Quiz 2 on Thurs Have your P3 groups ready by Thurs If you don’t pick them, I will. Progress or Congress?. Last time: Micro-tests MVC reprised; MV implementation DebugLog Today:
E N D
Mimesis and Compositing SWING Lecture 17, Oct 27 2009
Administrivia • Reminders: • Quiz 2 on Thurs • Have your P3 groups ready by Thurs • If you don’t pick them, I will...
Progress or Congress? • Last time: • Micro-tests • MVC reprised; MV implementation • DebugLog • Today: • Words to the wise: user input validation • Design principle: mimesis • UIs in SWING • The Composite design pattern
Words to the wise... http://xkcd.com/327/
Design Principle o’ the Day Principle of mimesis:Make the structure of your code mirror the structure of the thing that you are representing.
Mimesis • Real world has already solved design problem once • A solution exists; steal it where you can • Exploits human visualization/reasoning capabilities • Improves self-documentation • Sometimes worth introducing objects that exist only to name conceptual things
Mimesis: examples • Project 2: • CustomerType • EmployeeType • World • Receipt • Plant • AssemblyLine
Mimesis: corollary 1 • Verbs are things too... • Event.execute() • Dispatcher.dispatch() • OrderContainerFactory.newOrderContainer()
Mimesis: corollary 2 • If the thing is completely abstract (no “real world” counterpart) • Make up a visual process for it • Then mimic that...
Mimesis: corollary 2 • If the thing is completely abstract (no “real world” counterpart) • Make up a visual process for it • Then mimic that... • Example: P1 design • Based on thinking about clerks at the census bureau
Application: SWING • SWING designed to be modular • “glue together” components • Massive PITA to write GUI code by hand • Can become a real morass of spaghetti code and/or immense method bodies • Instead, make structure of GUI code mimic structure of the display
plantButtons configPanel configFrame plantViz The Viz configuration
exptConfig assemblyLineViz plantEmplViz lineBuilderViz The Viz configuration
Code goes the same way... • _configFrame.add(_buildConfig()); • private Component _buildConfig() { • final JPanel result=new JPanel(); • result.add(new PlantViz()); • result.add(_buildPlantButtons()); • return result; • } • public class PlantViz extends JPanel { • public PlantViz() { • super(); • this.add(_buildExptConfig()); • this.add(_buildPlantEmployeeViz()); • this.add(_buildLineViz()); • }
Another Design Pattern • So why does this nested design work? • Why can we get away with stuffing widgets (JPanel, JScrollPane, JButton, etc.) inside other widgets (JPanel, JScrollPane, etc.) willy-nilly? • Composite Design Pattern
Composite • Problem to solve: • Conceptual containers (JPanel, JScrollPane) • Conceptual “leaf” widgets (JButton, JTextArea) • Part-whole structure • Want the code to treat both uniformly • Don’t want to have to distinguish between leaf and container in client code