I’m trying to understand its functionality better. It looks similar to a design pattern called the decorator pattern?
So the wrapper “wraps” over what we need to encapsulate?
I’m trying to understand its functionality better. It looks similar to a design pattern called the decorator pattern?
So the wrapper “wraps” over what we need to encapsulate?
I assume this is for the RPG course, so I took the liberty of tagging the the topic with rpg.
We use the Saving Wrapper as an input provider for the Saving System, as well as managing automatically restoring the game to the correct state when the game starts with a save file in place. We separate that logic from the actual Saving System to keep the SavingSystem itself as pure and generic as possible.
Yes it is thanks.
So I am accurate in saying its a decorator pattern that creates greater encapsulation? I am just trying to understand all the terms.
So an interface would not serve our needs here?
I wouldn’t consider the SavingWrapper to be a Decorator pattern. A better example of the Decorator pattern is found in the ISaveable interface, which transforms any class into something that can capture or restore data.
An interface would not be helpful for the SavingWrapper itself.
Ok, so term wise what would the SavingWrapper be? Is it a pattern?
Not everything is a pattern.
Probably too late to answer, but I found the questions interesting so I’ll give it a go.
The SavingWrapper
term-wise is, well… a wrapper. Wrappers encapsulate (wrap) the functionality of a class, in this case, the SavingSystem
. This is particularly useful when creating libraries, you leave the functionality out of a class so you only need to modify the wrapper class when reusing the code in another project, really useful and saves a lot of time. This is achieved thanks to what @Brian_Trotter described, it helps keep the other classes pretty generic.
I hope this helps anyone who reads this thread.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.