What name should I give to these two classes that have been split into one class?
I recently did a refactoring. Basically, we have a system that reads an XML file and performs some operations on it, and then updates and writes it. I have split this functionality into two classes
- A class that "controls" XML and abstractly tells what to do with it
- A class that handles everything with XML and provides a simple interface for updating and reading what # 1 is about
The implementation is now significantly clear. # 1 no need to worry about XML namespaces or XPath queries or any of them. It just says "hey # 2, update this part from" foo "to" bar "".
However, I'm not sure how to call it. The old class got its name FooManifestXml
. What should I call these two classes? I have some ideas, but I would not skew the results.
Also, the big reason I'm worried about this simple naming is that there will be more refactorings done in the future like this and I would like to have an intuitive naming scheme for it
source to share
Sounds like a Team Template with minor changes.
A class that "manipulates" XML and abstractly tells what to do with it
It could be ICommand
public interface ICommand
{
void Execute();
}
A class that handles everything with XML and provides a simple interface for updating and reading what is 1 worried about
This can contain the implementation of actions:
public class UpdateCommand : ICommand
{
private XML file;
public UpdateCommand(XML file)
{
this.file = file;
}
public void Execute()
{
//omn nom nom xml
}
}
And it main
might look like
XML file = new XML("file.xml");
ICommand updateCommand = new UpdateCommand(file);
updateCommand.Execute();
source to share
At a high level, I think of it like this:
storage:
- Filesystem
- Database
- Memory
With a clear storage abstraction ( AbcStore or AbcRepository ), you can easily add behaviors like caching or locking.
Serialization format:
- XML
- Json
- ProtoBuf
Why did you choose XML, this may change, or perhaps the data will be available in different formats for different clients. I don't know enough about your statement to know if it makes sense.
I would call this abstraction AbcSerializer .
Business logic:
This is where you manage the data, and the method names should be in the problem domain, not in the solution domain. I mean this method name should be something like changeAddress
, notupdateChildNode
source to share