Должен ли я позволить объекту удалить себя из его интерфейса? Это правильно для ООД? - PullRequest
Новая
       22

Должен ли я позволить объекту удалить себя из его интерфейса? Это правильно для ООД?

1 голос
/ 01 мая 2011

У меня есть следующее: 

interface File
{ 
  String name();
  ...
}

interface FileService
{
  List<File> getAllFiles();
  ...
}

При работе с таким интерфейсом Если я решил удалить объект, представленный экземпляром файла (я имею в виду удалить с удаленного сервера), как мне это сделать??

Должен ли я ввести метод delete() для интерфейса файлов (так как это информационный эксперт и, возможно, знает, как удалить себя с сервера)?Или я должен делегировать эту функцию ее создателю - FileService через void deleteFile(File file) метод интерфейса?И почему?

Если первый случай более уместен, как сделать объект недействительным, чтобы избежать его последующего использования?

И связанный: как мне обращаться с uploadFile() случаем?Кто должен нести ответственность за это?Потому что кажется, что FileService, возможно, нарушит SRP.

Спасибо,

Ответы [ 2 ]

1 голос
/ 14 июня 2011

На мой взгляд, это должно быть обязанностью FileService.Причина и предположения:

Предположение - любой объект типа файла представляет файл, который извлекается откуда-то.Это не имеет значения для потребителя.Я считаю, что реализация файлового сервиса - это та, которая выполняет CRUD-операции над файловым объектом.Я также считаю, что Fileservice больше заботит управление файлами.Поэтому удаление должно быть на файловой службе.Если в объекте File присутствует операция удаления, то я считаю, что операции с файлами не связаны друг с другом и не разбросаны по классам.Это мое мнение, хотя.Я хотел бы услышать другие мнения!Кстати, класс FILE статический в Java?

1 голос
/ 01 мая 2011

Я думаю, что это должно быть на File.

Если у вас есть только один FileService (на соединение с сервером), который функционирует как Фабрика файлов, вы, вероятно, захотите, чтобы эта служба поддерживалана свидание.Затем вы могли бы использовать что-то: 

FactoryServiceImpl implements FactoryService {

    public File findFile(criteria) {
        return new FileImpl(this);
    }
}

// This should be package scope!
FileImpl implements File {
  private FactoryService service;

  // package scope!
  FileImpl(FactoryService service) {
      this.service = service;
  }

  public delete() {
      // invalidate this object - all calls should throw exception

      // Inform the service that this File should be deleted from
      // the server; or if the FileImpl does that itself, that the
      // FileService should update the cache of available files
      service.delete(this);
  }
}

EDIT

Там сейчас циклическая зависимость, которая невелика.JVM, вероятно, может обнаружить его и очистить любой материал, но вы также можете использовать WeakReference.

Выбор дизайна - неважно, идете ли вы с тонкой фабрикой и файлом фактов, или наоборот.Но они должны иметь возможность общаться, поскольку файл, который удаляется через фабрику, должен знать , что он был удален.

Некоторый код (предполагает фабрику фактов): 

// This should be package scope!
FileImpl implements File {
  private Weakreference<FactoryService> serviceRef;

  // package scope!
  FileImpl(FactoryService service) {
      this.serviceRef = new WeakReference<FactoryService>(service);
  }

  public delete() {
      // invalidate this object - all calls should throw exception

      // Inform the service that this File should be deleted from
      // the server; or if the FileImpl does that itself, that the
      // FileService should update the cache of available files

      FactoryService service = serviceRef.get();
      if (service != null) {
          service.delete(this);
      }
  }
}

В этом случае я предполагаю фабрику фактов, так как, вероятно, задействовано сетевое соединение, и разделение соединения между несколькими объектами и потоками, как правило, делает неясной ответственность за закрытие этого соединения.

Это имеетвследствие этого интерфейс FactoryService должен иметь метод close() или dispose(), который завершает соединение и делает недействительными все файлы (поскольку они больше не доступны).

EDIT 2

Что касается OOD, я бы, вероятно, попытался имитировать Java File API, насколько это возможно.Таким образом, объект может быть удален сам.Независимо от того, находится ли реализация в File или где-либо в FileSystem (для интерфейса и пользователей класса).

...