Я никогда не знаю, как правильно моделировать ситуации, когда есть такая структура данных, которую я хочу позже сохранить на диске.
Например, я сейчас работаю над небольшим генератором кода. Общая идея заключается в том, что я где-то захочу сохранить как квалифицированное имя класса, так и связанное с ним содержимое, и позже я захочу сохранить файл .java на диск и скомпилировать его с помощью javac
. Не совсем ясно, что я хочу выполнить оба действия, то есть сохранить на диск как .java и скомпилировать через javac
как одно действие. Я думаю, иногда мне может понадобиться просто записать файл .java на диск без компиляции.
class CompilationUnit {
String qualifiedName;
String contents;
}
Теперь мой вопрос о том, как смоделировать это. Если у меня есть CompilationUnit
, который принимает в качестве аргументов и IFileSystem
, и IJavaCompiler
, поэтому каждый раз, когда у меня "в руках" a CompilationUnit
, у меня есть все необходимое для выполнения обоих действий, или я должен стараться сохранить эта логика компиляции вне класса, являющаяся CompilationUnit
просто объектом данных?
С одной стороны, существует ОО-убеждение, что следует хранить и состояние, и поведение на одном и том же объекте, что будет способствовать сохранению квалифицированного имени и его содержимого вместе с возможностью записи модуля компиляции на диск и его компиляции.
Несмотря на этот факт, я не могу не чувствовать себя неудобно из-за того, что CompilationUnit
принимает зависимости IFileSystem
и IJavaCompiler
, хотя мне немного сложно объяснить, почему это так.
Моя (идеалист?) Интуиция заключается в том, что объект данных должен легко создаваться, и с этой точки зрения он не может не чувствовать себя неловко, передавая IFileSystem
и IJavaCompiler
каждый раз, когда я хочу сохранить квалифицированный имя и его содержание вместе. Это означает, что тот, кто отвечает за генерацию этих данных, должен также иметь доступ к IFileSystem
и IJavaCompiler
, что довольно странно.
Я не уверен, что на самом деле ответил на свой вопрос или нет.
Эта система будет протестирована, поэтому правильная обработка проблем с зависимостями имеет первостепенное значение.
Спасибо!