5
public void Save(string filename, bool overwrite = false)
{
File.WriteAllText(filename, ToString());
}
This approach is problematic. The journal’s responsibility is to keep
journal entries, not to write them to disk. If you add the persistence
functionality to Journal and similar classes, any change in the approach
to persistence (say, you decide to write to the cloud instead of disk) would
require lots of tiny changes in each of the affected classes.
I want to pause here and make a point: An architecture that leads to you
having to make lots of tiny changes in lots of classes, whether related (as in
a hierarchy) or not, is typically a code smell—an indication that something’s
not quite right. Now, it really depends on the situation: If you’re
renaming a symbol that is being used in a hundred places, I would argue
that’s generally okay because ReSharper, Rider, or whatever integrated
development environment (IDE) you use will actually let you perform a
refactoring and have the change propagate everywhere. When you need to
completely rework an interface, though, it can be a very painful process!
We therefore state that persistence is a separate concern, one that is
better expressed in a separate class. We use the term separation of concerns
(sadly, the abbreviation SoC is already taken) when talking about the
general approach of splitting code into separate classes by functionality. In
the cases of persistence in our example, we would externalize it like so:
public class PersistenceManager
{
public void SaveToFile(Journal journal, string filename,
bool overwrite = false)
{
if (overwrite || !File.Exists(filename))
File.WriteAllText(filename, journal.ToString());
}
}
Chapter 1 the SOLID DeSIgn prInCIpLeS
我的内容管理
展开
