Suppose of this question the following:
- I’m in full control of this project
- I’m writing a media player
Obviously, a media player will allow a user to adjust the volume, so I might have a class that looks like this:
public class Audio {
private int level;
// Constructor and other attributes left out
public int getCurrentVolume()
public void turnUp(int amount)
public void turnDown(int amount)
}
My media player will also allow you to take screenshots of current video, so I might have a class that looks like this:
public class Video {
private String screenshotsDirectory;
// Constructor and other attributes left out
public String getCurrentScreenshotDirectory()
public updateScreenshotDirectory(String newScrenshotPath)
}
Problem:
At some point, you’ll write and read the data from a file, the problem is, you have have to create a stream for each type.
FileWriter volumeWriter = new FileWriter("settings.txt");
volumeWriter.writer(audioObj.getCurrentVolume());
FileWriter videoWriter = new FileWriter("settings.txt")
videoWriter.writer(videoObj.getCurrentScreenshotDirectory());
It would be nice to pass the FileWriter object an abstract type, which means I could make an abstract class or interface called Settings, but as far as I can see the settings don’t share common behavior. Sure, the settings can change, but in different ways, for example, the screenshot path is a String while volume is an int.
Question:
What is the clean OOP way to structure classes that are on the same type (configuration/user settings), but can change and behave in different ways?
I can turn up the volume and change the screenshot path, but I cannot “turn up” the screenshot path or update the volume with a String (representing the path).
“Settings” are a classic cross-cutting concern similar to logging, caching etc. The simplest way to handle settings is to treat it as a singleton and have your Audio and Video classes directly interact with the settings class.
The general idea is to decouple the in-memory representation of settings (which could be a simple HashMap) from how it is persisted (file/registry, XML/JSON etc.). Java has a built-in Preferences API that works this way.
I’ll suggest the application of an oft-repeated part of the Unix philosophy: do one thing, and do it well. And yes, that rule is applicable to objects (and functions, and data structures in general, and multi-program systems, and…), not just programs.
So, what’s the one thing? An audio player? A video player? A file reader?
I’d suggest starting off by taking your settings.txt file, and having a single object that reads it, and then gets queried for values. After all, you can justify building a class that just does a good job of reading & writing that file instead of dragging the entrails of it’s parsing code all over the place, right? Parsing your settings file deserves to be listed as “one thing” under the philosophy.
After that, it seems to me that things get a bit more opaque. Do you want your audio & video classes to constantly have the same values after they get instantiated, or not? If their values should change, then do they go looking for changes, or get explicitly told about them? Do you want an interactive control object somewhere in all this? Do you want to chain video & audio classes? All of this needs to be decided, and individual bits picked out and run through the philosophical rule for the sake of producing clean, easily used “atoms” that can be substituted into the “final goal” for the sake of simplifying it.