Сложный дизайн объекта

Question

Допустим, у вас есть концепция «DataPackage», которая физически представляет собой zip-архив. Вам необходимо внедрить систему для управления пакетами данных, типичные сценарии: «импортировать новый», «удалить существующий» и т. Д. Есть причины, по которым вы не можете сохранить эти файлы в базе данных.

Вопрос в том, как разделить концепцию «DataPackage» на классы, которые работают отдельно с «аспектом данных» (вещи, связанные с БД) и «аспектом файловой системы» (вещи, связанные с файлами)?

Я думаю о следующем:

// data package concept
interface DataPackage {
  string GetFileName();
  DataTime GetDateTimeImported();
}

// data package manager concept
interface DataPackageManager {
  DataPackage[] GetAllDataPackages();
  DataPackage ImportDataPackage(string sourceFileName);
  void DeleteDataPackage(DataPackage dataPackage);
}

// data package database aspect
interface DataPackageData {
  int GetId();
  void SetFileName(string fileName);
  string GetFileName();
}

// data package database manager
interface DataPackageDataManager {
  DataPackageData[] GetAllDataPackagesDatas();
  DataPackageData CreateDataPackageData();
  void DeleteDataPackageData(DataPackageData data);
}

// also, similar 2 classes for DataPackage's filesystem aspect
// these would be responsible for copying files, removing files, etc

Является ли это нормальным дизайном, если проблема, которую я пытаюсь решить, - это "как можно более простые" реализации для DataPackage и DataPackageManager? В настоящее время все эти вещи реализованы в DataPackage и DataPackageManager, и я думаю, что то, что я здесь предлагаю, лучше, чем то, что у меня есть.

Answer 1

Как насчет инкапсуляции DataPackage в два разных класса, один для вещей, связанных с базой данных, и другой для операций, связанных с файлами.

DBDataPackageManager {
DataPackage dataPackage;
//get, set, remove, modify etc etc
}

FileDataPackageManager {
//file operations on DataPackage object.
}