разработка виртуальной файловой системы

[ТриСемёрки]

Задание
Разработать иерархию классов для организации виртуальной файловой системы. Иерархия включает проектирование не менее четырех интерфейсов: IVFSObject, IFile, IDirectory, IVFS. IVFSObject – является предком IFile и
IDirector, а так же содержит общий для них набор методов. Каждый экземпляр записи виртуальной файловой системы реализует методы интерфейса IVFSObject. В свою очередь интерфейсы IFile и IDirectory расширяют набор методов IVFSObject, каждый согласно своей функциональности. Интерфейс IVFS содержит методы доступа к метаинформации конкретного драйвера виртуальной файловой системы. В частности, он должен содержать методы получения таких данных как название используемого драйвера файловой системы, используемая кодировка в именах файлов и т.д. Кроме того, IVFS содержит метод доступа к корневому элементу файловой системы.
Разработка виртуальной файловой системы включает создание не менее трех драйверов в виде соответствующего набора классов. Это означает, что необходимо создать группу классов, реализующих каждый спроектированный интерфейс для своего типа драйвера представления данных. Таким образом, основной код программы не будет зависеть от типа драйвера, способа представления, хранения и организации файловой системы в памяти, так как будет ориентирован на использование экземпляров интерфейсных типов переменных. За счет такого подхода достигается полиморфизм исходного кода, который использует экземпляры разработанных классов. В качестве примера типов драйверов можно выбрать следующие представления реализаций файловой системы в памяти: native -работа с системными вызовами ОС, block – хранение файловой системы в виде одной записи (бинарного файла) на логическом диске ОС, ftp – доступ к файловой системе с использование сетевого протокола передачи файлов.
Для реализации выбора при создании экземпляра класса конкретного типа драйвера представления файловой системы необходимо использовать фабрику классов. Решение о выборе типа возвращаемого экземпляра фабрика принимает на основании входных параметров или внешнего конфигурационного файла.
Дополнительно рекомендуется реализовать методы монтирования и демонтирования различных файловых систем между собой по аналоги с UFS (файловой системы unix), таким образом, что каждый объект файловой системы может также является точкой монтирования IMountPoint, которая также является расширением IVFSObject.
При проектировании системы необходимо самостоятельно принять решение о целесообразности использования того или иного подхода для организации взаимодействия между объектами. Обосновать свой выбор теоретически.

ПОМОГИТЕ С ТЕОРИЕЙ!!! В ЛЕКЦИИ ТОЛЬКО ООП!

[Stilet]

Это... красный диплом?

[ТриСемёрки]

Это лабораторная работа на 4 часа времени. (Мне как заочнику 4 часа маловато)

Помощь! Мне нужна помощь!

[pu4koff]

Я так понял, всё таки виртуальную ФС как таковую создавать не нужно и слово драйвер тут для красного словца (а иначе всё будет грустно).
Теория в таком случае за исключением ООП никакая и не нужна. Пишите себе интерфейсы типа:

// Объект файловой системы
class IVFSObject
{
public:
  virtual ~IVFSObject() {} // не забываем о виртуальном деструкторе
public:
  virtual char* get_name() = 0; // имя объекта
  virtual IVFSObject* get_parent() = 0; // родительский объект
};
// Директория. Расширяет возможности IVFSObject
class IDirectory: public IVFSObject
{
public:
  virtual int get_child_count() = 0; // Число "детей"
  virtual IVFSObject** get_child() = 0; // Массив "детей" директории
}
...
// Фабрика для драйверов
// Методы можно пометить как static
class VFSFactory
{
public:
  IVFS CreateFileVFS(); // Создаем драйвер для обычной файловой системы
  IVFS CreateFTPVFS(); // Создаем драйвер для файловой системы FTP
};

и реализуйте всё это уже в классах-потомках

[ТриСемёрки]

Наконец-то луч света в тёмном царстве! Однако остаётся непонятным, какие различия должны быть между классами-потомками ( native , block , ftp - если я правильно понял) и как должна выглядеть работа готовой программы ? Может всё-таки без теории не обойтись(но с другой стороны на работу в планах давалось 4 часа и => работа не слишком "глубокая").

[Stilet]

Дурость какая-то... Чем там преподаватели думают давая такое...
Если уж и писать что-то вроде файловой системы то:
1) Описать класс "файл" (или "устройство"), который будет иметь поле типа массива байтов (или строку, я люблю string использовать в качестве массива байтов)
2) Этому классу отвести поле - список папок, и файлов входящих в него
3) Не забыть указать тип класса - файл это или папка.

И вот представь что такая иерархия даст тебе практически реальную файловую систему почти похожую на стандартные каталоги

[pu4koff]

Да уж. Странная задача на 4 часа... По этому заданию можно тут чуть ли не половину ОС написать. Что хочет препод до конца не понятно

[Stilet]

Что хочет препод до конца не понятно

Наоборот Все тут понятно. Препод жаждет таки избавится от половины класса в пользу армии )))

[pu4koff]

В принципе можно реализовать такие варианты:
1) работать с реальной ФС компа (через всякие FindFirst, FindNext и т.п. если речь о винде.) Это и подразумевалось под словом native я так понимаю
2) Если умеете работать с БД, то можно быстренько слепить подобие ФС на каком-нибудь sqlite
3) Хранение ФС в бинарнике. Почитайте про сериализацию для облегчения задачи. Если MFC используется, то заготовки для сериализации там уже есть. Вероятно, это имелось ввиду под словом block.
4) Можно и с FTP работать, найдя соответствующую библиотеку... но всё это не на 4 часа. Нереально это всё сделать за 4 часа. Интерфейсы продумать можно. Ну реализовать native "драйвер" - это еще реально в принципе. Но 3 драйвера... Жестко

[ТриСемёрки]

Прошу прощения за долгое отсутствие. И первый, второй и третий варианты в виде заготовок есть в MFC. А как подключить MFC в C++Builder 6?