basisklassendesign so in ordnung?

[otze]

also, ich habe mir 2 basisklassen geschrieben, die hinterher das arbeiten mit dateisystemen erleichtern sollen, und bevor ich weiter mache, wollte ich fragen, was ihr davon haltet(bei designfragen hab ich teilweise noch arge probleme)

//folder.hpp
class File;

class Folder{
	private:
		typedef boost::filesystem::path Path;
		typedef boost::shared_ptr<File> FilePointer;
		typedef boost::shared_ptr<Folder> FolderPointer;
	public:

		virtual const Path& getPath()=0;

		virtual FilePointer openFile(Path& relativePath)=0;
		virtual FolderPointer openFolder(Path& relativePath)=0;

		//functions for file/folder enumerations
		virtual	FilePointer nextFile()=0;
		virtual FilePointer previousFile()=0;

		virtual FolderPointer nextFolder()=0;
		virtual FolderPointer previousFolder()=0;

		virtual std::size_t getFileCount()=0;
		virtual std::size_t getFolderCount()=0;

};

mir gefällt die sache mit nextXXX/previousXXX nicht, aber iteratoren funktionieren in diesem fall ja auch nicht so ohne weiteres

//File.hpp
class Folder;

struct File{

	virtual boost::shared_ptr<Folder> getParent()=0;

	virtual boost::filesystem::path getPath()=0;

	virtual std::istream& getReadAccess()=0;
	virtual std::ostream& getWriteAccess()=0;

};

ich bin für tips und anregungen immer dankbar

[Shade Of Mine]

otze schrieb:

mir gefällt die sache mit nextXXX/previousXXX nicht, aber iteratoren funktionieren in diesem fall ja auch nicht so ohne weiteres

Warum?

[otze]

warum iteratoren nicht sogut funktionieren?
wenn ich in Folder vorgebe, was für ein iterator zurückgegeben werden soll, dann nehm ich Derived die möglichkeit, einen eigenen iterator zu implementieren, da sonst die rückgabewerte der methoden nichtmehr übereinstimmen.
Die andre möglichkeit wär eine basisklasse für einen iterator, von dem jeder Derived einen eigenen iterator ableitet. imho eher unschön als lösungsmöglichkeit.
was bleibt dann noch?

[otze]

wenn euch ein code so ein Folder objekt/file objekt vor den latz knallen würdet, was würdet ihr für anforderungen an ein solches objekt stellen? reicht das, was fodler ebreits kann? sollte file mehr können? wie sollte es sich anfühlen, diese objekte zu benutzen?

[ssm]

ich würde lieber sowas benutzen:

class FileSystemObject
{
	FileSystemObject();
	FileSystemObject(const FileSystemObject&);
	FileSystemObject(const Path&);

public:
	typedef FileSystemIterator<FileSystemObject> iterator;
	typedef FileSystemIterator<const FileSystemObject> const_iterator;

	//factory method
	static createObject(const Path&, FileSystemObject *obj);

	//iterators for child files/folders, 
	//if current is folder
	iterator begin();
	iterator end();
	const_iterator begin() const;
	const_iterator end() const;

	//accessors
	Path getPath() const;		//current path	
};

[otze]

für mich ist das design so nicht zu gebrauchen:
diese folder-objekte sollen hinterher aus ordner auf der festplatte, wie auch aus archiven erstellt werden, und da sind nonvirtual ansätze nicht zu gebrauchen.

ansonsten zu dem iterator ansatz:

der standard erlaubt ja, dass wenn die basisklasse ein base& zurückgibt, die abgeleitete klasse ein derived& zurückgeben kann,neben der tatsache, dass wir hier weder referenz noch pointer zurückgeben,und somit der ansatz eh kaputt ist, kommt allerdings die frage auf, ob der standard erlaubt, dass in der basisklasse foo<Base> und in der abgeleiteten Klasse foo<Derived> benutzt werden kann(thema unterschiedliche schnittstellen)