locked
Kindly give me a suggestion about a good look design of PathProvider Class. RRS feed

  • Question

  • Well, this is a very simple question in this forums. Hope anyone could give me a quick suggestion.

     

    I'm about to implement a PathProvider class, which is used to provide the specific file path to any IO relative functions.

    My leader wants to put all folder paths & file names in this class, any IO operation against to any specific file should call this class to get the specific file path.

    So, there are many methods like GetXXXFilePath(), and many const string in this class.

    And mean while, our software product is kind of big, so many file accessed by app, so....the const string and GetXXXFilePath() method become more and more, the scale of this class is too big I think.

    Any quick suggestion could make this a better design?

     

    Thanks very much.

    Friday, March 18, 2011 8:20 AM

Answers

  • Hi,

     

    I'm not a software architect but I would always recommend against this way of working.

    Why not go for:

    GetFilePath()

    GetFilePath(string folder)

    etc

    I think you can work this out very deep. My advise try beginning small. Else you'll be designing and modeling for ages without producing something.

    For instance take a look at the param (string folder). I can think of 10 different implementations:

    - using an enum

    - only check for for folders or files as well

    - what if we find a folder/file with identical names

    - should we return subfolders and if so should we also return files etc.

     

    Dunno what you're planning here but I think an enum would help a lot here. Problem is that I do not know if the folder structure will change. If so the enum will soon fail. An enum short or too many (a deleted folder) so you need to come up with a dynamic solution.

     

    HTH

    Friday, March 18, 2011 11:01 AM
  • I can't see why he would want one method per file.  Add another file and you need to code another method.  That seems so wrong - I'm wondering what his reasoning could possibly be.

    GetFile(some sort of parameter)

    Makes much more sense to me.

    Store your parameters in an xml file, database, string enum or whatever. 

    Friday, March 18, 2011 1:49 PM

All replies

  • Hi,

     

    I'm not a software architect but I would always recommend against this way of working.

    Why not go for:

    GetFilePath()

    GetFilePath(string folder)

    etc

    I think you can work this out very deep. My advise try beginning small. Else you'll be designing and modeling for ages without producing something.

    For instance take a look at the param (string folder). I can think of 10 different implementations:

    - using an enum

    - only check for for folders or files as well

    - what if we find a folder/file with identical names

    - should we return subfolders and if so should we also return files etc.

     

    Dunno what you're planning here but I think an enum would help a lot here. Problem is that I do not know if the folder structure will change. If so the enum will soon fail. An enum short or too many (a deleted folder) so you need to come up with a dynamic solution.

     

    HTH

    Friday, March 18, 2011 11:01 AM
  • I can't see why he would want one method per file.  Add another file and you need to code another method.  That seems so wrong - I'm wondering what his reasoning could possibly be.

    GetFile(some sort of parameter)

    Makes much more sense to me.

    Store your parameters in an xml file, database, string enum or whatever. 

    Friday, March 18, 2011 1:49 PM
  • Why not just look at System.IO?

     


    http://pauliom.wordpress.com
    Friday, March 18, 2011 4:08 PM
  • @pkr2000 i think (hope) they discarted that option

    @andy1559 - that method is way better (that's what I ment with more dynamic).

    @honywellchapter maybe you could try a dev group forum for implementation details?

     

     

    Saturday, March 19, 2011 8:09 AM