1. Pattern Hatching - John Vlissides Pages 85 – 101 Todd Anderson
Generation Gap
Pattern Hatching - John Vlissides
Pages 85 – 101
Todd Anderson

2. Pattern Basics PATTERN NAME Generation Gap CLASSIFICATION
Class Structural
INTENT
Modify or extend generated code just once no matter how many times it is regenerated.
MOTIVATION
Having a computer generate code for you is usually preferable to writing it yourself, provided the code it generates is
correct,
efficient enough,
functionally complete, and
maintainable.

3. Motivation (continued)
Many code generation tools have no problem generating code that's correct and efficient.
The difficulty with these tools is their attempt at creating functionally complete software that is maintainable.
Developer has to write some of the code.
Developer needs to be able to understand what the generated code in order to modify.

4. Example – Alarm Clock
An alarm clock application built with an interface builder application
Tool provides developer with:
Widgets (buttons, scroll bars, etc)
Primitive graphical objects (lines, circles, etc)
Ability to associate behavior with drawn items.

5. Clock Interface

6. Clock Operations
Once the interface has been generated the developer would add functionality to the code.
A 1-second interval event
Rotating the clock hands
Setting the alarm
Turning alarm off
Etc…
Does anyone see a problem with this?

7. Maintenance Problem What if you want to rearrange the user interface?
What if you want to move buttons?
What if you resize the clock?
Regenerating the code blindly will clobber any changes or at least force you to reapply them.

8. Simple Solution
Generation Gap is a pattern that solves this problem through class inheritance.
It encapsulates generated code in a class and then splits that class into two:
One class for encapsulating generated code (Clock_core)
One for encapsulating modifications (Clock)
Core class is Never modified by subclass.
Code intantiates object with subclass (Clock)
Modifications go into subclass (Clock)

9. Simple Solution

10. Applicability Apply Generation Gap when all of the following are true:
Generated code can be encapsulated in one or more classes.
Code is generated automatically.
Regenerated code usually retains the inteface and instance variables of the previous generation.
Generated classes usually aren't integrated into existing class hierarchies.

11. Structure

12. Participants CoreClass (Clock_core)
an abstract class containing a tool-generated implementation.
is never modified by hand.
is overwritten by the tool on regeneration.
CoreSubclass (Clock)
a trivial subclass of CoreClass.
implements extensions of or modifications to CoreClass. A programmer may change it to add state and/or extend, modify, or override CoreClass behavior.
extensions or modifications are preserved across regenerations.
Client
instantiates and refers to CoreSubclass only.

13. Collaborations
CoreSubclass inherits tool-generated behavior from CoreClass, overriding or extending its behavior.
CoreClass exposes and/or delegates select functionality to CoreSubclass to allow modification or extension of its behavior.

14. Consequences - Benefits
Modifications are decoupled from generated code
Modifications can have privileged access to implementation details.
CoreClass & ExtensionClass may be developed and tested independently
Subsequent regeneration does not require reapplying the modifications.
While the modifications will not need to be reapplied, they may need modification themselves if
modifications refer to members that no longer exist
regenerated code differs semantically from its previous incarnation so that operations no longer mean the same thing
Both incompatibilities diminish the pattern's effectiveness, so they must not be inherent to the code being generated.

15. Consequences - Liabilities
Doubles the number of classes.
Integrating generated classes into existing class hierarchies may be difficult.
Making the extension class inherit from an existing class requires multiple inheritance.

16. Implementation Disallowing modifications to the core class.
Cardinal requirement for this pattern
Controlling access to core class internals.
The more information CoreClass exposes to subclasses, the more likely regenerating the code will break modifications to ExtensionClass.
Naming conventions.
CoreClass should derive its name from extension subclass
Granularity of CoreClass operations.
Keep operations fine-grained enough so that programmers can override precisely the functionality they’re interested in.

17. Sample Code – Core Class
class Clock_core : public MonoScene {
public:
Clock_core(const char*);
protected:
Interactor* Interior();
virtual void SetTime();
virtual void SetAlarm();
virtual void Snooze();
Picture* _clock;
SF_Polygon* _hour_hand;
SF_Rect* _min_hand;
Line* _sec_hand; };

18. Sample Code – Ext. Class Extension class before modification:
class Clock : public Clock_core {
public:
Clock (const char*); };

19. Sample Code – Ext. Class II
Extension class after modification:
class Clock : public Clock_core {
public:
Clock (const char*);
void Run();
virtual void SetTime();
virtual void SetAlarm();
virtual void Snooze();
virtual void Update();
private:
void GetSystemTime(int& h, int& m, int& s);
void SetSystemTime(int h, int m, int s);
void Alarm();
float _time;
float _alarm; };

20. Known Uses
Generation Gap did not make the cut because of a lack of known uses at the time.
Ibuild – Interface builder
Reader’s noted other examples
Blue Sky’s Visual Programmer
CORBA Stub generator

21. Related Patterns
Core classes often use template methods to maximize reuse of generated functionality
Factory Methods can give extension classes control over the objects that the core class uses internally.

22. Questions