2 examples of lesser know designs related to GOOS
55 views
Skip to first unread message
Luca Minudel
Jun 18, 2025, 11:02:26 AMJun 18
to Growing Object-Oriented Software
Hey there! I recently came across some of my old code examples and gave them a little update.
SMART HANDLERS
=====================
The paper 'Endo-Testing: Unit Testing with Mock Objects' suggests that developing with Mock Objects often leads to the creation of Visitor-like objects that are passed around; they (Tim Mackinnon, Steve Freeman, Philip Craig ) referred to these as Smart Handlers.
The first example (in C#) illustrates one of these smart handlers.
The version named Worse shows how applying SRP to the class GuidedTourGroups, and therefore splitting it into GuidedTour and Group, leads to exposing Group internal state with getters.
While the version named Better does without the getters and instead uses GuidedTour as a smart handler / visitor to the Group object that ultimately Registers itself to the GuidedTour passing directly the relevant info to it.
All this is here linked at the bottom of the readme
OBJECTS RELATIONSHIPS ENCAPSULATION
========================================
The techniques from GOOS
The original discovery of Mock objects and the related techniques was triggeredy by the of writing code without getters, set by John Nolan.
This challenge was strogly related to the 'Law of Demeter' (Ian Holland, Karl J. Lieberherr, Arthur J. Riel; 1987).
Karl J. Lieberherr in his book Adaptive Object-Oriented Software (1995) explores furthert the aspects of 'Law of Demeter' related to encapsulation and low coupling in relation to the traversal of objects graph and the code changes needed (due to requirements changes/evolutions) when some of these object relationships changes.
Karl J. Lieberherr came up with the idea of encapsulating not only objects internal state and implementation details but also the traversal of objects graph/relationships so that changes to graph/relationships would require minimal and localised code changes.
In that book it looks for a generic solution that could be implemented by an automatic tool.
This coding exercise instead tryes to find a specific design solution that minimise the code changes required when the graph of object relationship changes.
Specifically the code examples provided, Exercise 1 requires several code changes to the object graph traversal when the new requirements are added. Exercise 2 instead minimises the changes required when the the object graph changes.
Exercise 2 the graph traversal and the work done when traversing the graph is encapsulated in the objects of the graph.
The trade-off is that when the traversal logic changes (for example some filter condition is added) or the work done during the traversal changes (for exampl different info is collected) all objects require the same change.
This can be partially minimised encapsulating that responsibility in a base object.
Still there is a trade-off here, some big gain on one side (when the object graph changes) and some small losses on the other (when the traveral loging and work changes).
The two exercises are explained here
SMART HANDLERS
=====================
The paper 'Endo-Testing: Unit Testing with Mock Objects' suggests that developing with Mock Objects often leads to the creation of Visitor-like objects that are passed around; they (Tim Mackinnon, Steve Freeman, Philip Craig ) referred to these as Smart Handlers.
The first example (in C#) illustrates one of these smart handlers.
A smart handler design is part of a soluton proposed to solve a specific instance of tension betwen the SRP principle and Encapsulaition.
While the version named Better does without the getters and instead uses GuidedTour as a smart handler / visitor to the Group object that ultimately Registers itself to the GuidedTour passing directly the relevant info to it.
All this is here linked at the bottom of the readme
OBJECTS RELATIONSHIPS ENCAPSULATION
========================================
The techniques from GOOS
The original discovery of Mock objects and the related techniques was triggeredy by the of writing code without getters, set by John Nolan.
This challenge was strogly related to the 'Law of Demeter' (Ian Holland, Karl J. Lieberherr, Arthur J. Riel; 1987).
Karl J. Lieberherr in his book Adaptive Object-Oriented Software (1995) explores furthert the aspects of 'Law of Demeter' related to encapsulation and low coupling in relation to the traversal of objects graph and the code changes needed (due to requirements changes/evolutions) when some of these object relationships changes.
Karl J. Lieberherr came up with the idea of encapsulating not only objects internal state and implementation details but also the traversal of objects graph/relationships so that changes to graph/relationships would require minimal and localised code changes.
In that book it looks for a generic solution that could be implemented by an automatic tool.
This coding exercise instead tryes to find a specific design solution that minimise the code changes required when the graph of object relationship changes.
Specifically the code examples provided, Exercise 1 requires several code changes to the object graph traversal when the new requirements are added. Exercise 2 instead minimises the changes required when the the object graph changes.
Exercise 2 the graph traversal and the work done when traversing the graph is encapsulated in the objects of the graph.
The trade-off is that when the traversal logic changes (for example some filter condition is added) or the work done during the traversal changes (for exampl different info is collected) all objects require the same change.
This can be partially minimised encapsulating that responsibility in a base object.
Still there is a trade-off here, some big gain on one side (when the object graph changes) and some small losses on the other (when the traveral loging and work changes).
The two exercises are explained here
And the code examples are here
Hope someone finds this archeology re-discovery intresting :-)
Luca
Luca
philip schwarz
Jun 20, 2025, 12:47:32 PMJun 20
to Growing Object-Oriented Software
Thank you for sharing.
Philip
Reply all
Reply to author
Forward
0 new messages