I could have stored indices of Polygon in current Scene, index of dragged point in Polygon, and replace it every time. But this approach does not scale - when composition levels go to 5 and further, boilerplate would become unbearable.
You're absolutely right, this approach doesn't scale if you can't get around the boilerplate. Specifically, the boilerplate for creating a whole new Scene with a tiny subpart changed. However, many functional languages provide a construct for dealing with this sort of nested structure manipulation: lenses.
A lens is basically a getter and setter for immutable data. A lens has a focus on some small part of a larger structure. Given a lens, there are two things you can do with it - you can view the small part of a value of the larger structure, or you can set the small part of a value of a larger structure to a new value. For example, suppose you have a lens that focuses on the third item in a list:
thirdItemLens :: Lens [a] a
That type means the larger structure is a list of things, and the small subpart is one of those things. Given this lens, you can view and set the third item in the list:
> view thirdItemLens [1, 2, 3, 4, 5]
3
> set thirdItemLens 100 [1, 2, 3, 4, 5]
[1, 2, 100, 4, 5]
The reason lenses are useful is because they are values representing getters and setters, and you can abstract over them the same way you can other values. You can make functions that return lenses, for instance a listItemLens function which takes a number n and returns a lens viewing the nth item in a list. Additionally, lenses can be composed:
> firstLens = listItemLens 0
> thirdLens = listItemLens 2
> firstOfThirdLens = lensCompose firstLens thirdLens
> view firstOfThirdLens [[1, 2], [3, 4], [5, 6], [7, 8]]
5
> set firstOfThirdLens 100 [[1, 2], [3, 4], [5, 6], [7, 8]]
[[1, 2], [3, 4], [100, 6], [7, 8]]
Each lens encapsulates behavior for traversing one level of the data structure. By combining them, you can eliminate the boilerplate for traversing multiple levels of complex structures. For instance, supposing you have a scenePolygonLens i that views the ith Polygon in a Scene, and a polygonPointLens n that views the nth Point in a Polygon, you can make a lens constructor for focusing on just the specific point you care about in an entire scene like so:
scenePointLens i n = lensCompose (polygonPointLens n) (scenePolygonLens i)
Now suppose a user clicks point 3 of polygon 14 and moves it 10 pixels right. You can update your scene like so:
lens = scenePointLens 14 3
point = view lens currentScene
newPoint = movePoint 10 0 point
newScene = set lens newPoint currentScene
This nicely contains all the boilerplate for traversing and updating a Scene inside lens, all you have to care about is what you want to change the point to. You can further abstract this with a lensTransform function that accepts a lens, a target, and a function for updating the view of the target through the lens:
lensTransform lens transformFunc target =
current = view lens target
new = transformFunc current
set lens new target
This takes a function and turns it into an "updater" on a complicated data structure, applying the function to only the view and using it to construct a new view. So going back to the scenario of moving the 3rd point of the 14th polygon to the right 10 pixels, that can be expressed in terms of lensTransform like so:
lens = scenePointLens 14 3
moveRightTen point = movePoint 10 0 point
newScene = lensTransform lens moveRightTen currentScene
And that's all you need to update the whole scene. This is a very powerful idea and works very well when you have some nice functions for constructing lenses viewing the pieces of your data you care about.
However this is all pretty out-there stuff currently, even in the functional programming community. It's difficult to find good library support for working with lenses, and even more difficult to explain how they work and what the benefits are to your coworkers. Take this approach with a grain of salt.
The decorator pattern is typically used to avoid an explosion of subclasses. A common example involves UI windows that you may want to have any combination of n attributes (scrollbar, titlebar, resizable, movable, etc.).
Supporting all combinations of all those N attributes for all UI windows M subclasses would involve making N * M subclasses.
The decorator pattern prevents the explosion by wrapping around the base window class' existing public methods.
The decorator pattern ideally would only require N + M classes in this case.
For the case you have described, you are adding new public methods; therefore, the decorator pattern probably is not ideal. I cannot think of any situations where it would be ideal to add new methods via a decorator.
A few alternatives to consider:
Subtyping
It is valid to use subtyping to add methods, provided you are keeping the SOLID principles in mind. Therefore, you might consider extending the concrete object to support methodB and then design the decorator around it.
AbstractObject object = new ExtendedConcreteObject();
object.methodA(); // does stuff
object = new ConcreteDecorator(object);
(ConcreteDecorator)object.methodB();
// methodB() belongs to ExtendedConcreteObject() but not to AbstractObject()
Adapter Pattern
Another way to view the problem: by adding a public method, you are changing the object's interface. This can be done by using the adapter pattern. To keep the concrete decorator simple, you might consider creating a decorator and then building an adapter for that decorator.
AbstractObject object = new ConcreteObject();
object.methodA(); // does stuff
object = new ConcreteDecorator(object);
object = new ConcreteAdapter(object);
(ConcreteAdapter)object.methodB();
// methodB() belongs to ConcreteAdapter() but not to AbstractObject() or ConcreteDecorator().
Best Answer
A solution is to define a common interface that both Decorator and Decorated must implement. This interface should contain all the methods that must be decorated.
Additionally, Decorator must not be a subclass of Decorated, so that nothing is inherited from Decorated and Decorator must provide its own implementation for each method in the interface.
It is OK to have an instance of Decorated as a member variable of Decorator (strong aggregation): Decorator redirects all method calls to Decorated, as appropriate.