Question

I have a silly, little class “FileSystemSize” which can be used both as an object and also via public, static methods. The output is similar, but not identical in each case.

The class was intially static, but I added the possibility to initialize it as an object to allow extending with new “convenience methods” in future versions, without the need for a lot of parameter parsing. For example I have GetKBString(), GetMBString(), etc…methods to allow getting the file size conveniently formatted the way I want it (as a string). Internally the class stores the file byte size as a double.

I am a bit confused if this makes sense at all. It seems like I should perhaps split this into a static version and an object version like Microsoft does for Directory and DirectoryInfo. However it just seems easier to me to have this all in one place with a name that can’t be mistaken – it should be clear what FileSystemSize does? Are there any implications for maintenance that I am not anticipating? What’s that smell?

var mypath = @"C:\mypath";

var filesystemsize = new FileSystemSize(mypath);
string kilobytes = filesystemsize.GetKBString();
string megabytes = filesystemsize.GetMBString();
double bytes = filesystemsize.ByteSize;

double staticbytes = FileSystemSize.GetDirectoryBytesSize(new DirectoryInfo(mypath));
double statickilobytes = FileSystemSize.ConvertSize(staticbytes, "KB");

Answer 1

Look at it another way: Why are you putting String/Number/UI formatting methods in your FileSystemSize method?

While it can be used in respect of files, this is a general piece of functionality that IMHO should be found elsewhere in a well organised library – just as Path functions are not part of the File or Directory classes in .net, I would put the “format a number” methods in a string or maths utils class.

Separate the responsibilities of your objects and you may find there is no need to mix static and non-static members in cases like this.