In our CORE library we offer this class as a 20,000 line abstraction.
Can you see anything wrong with the way this is designed?
Note1: This class has a SharpZipLib backing.
Note2: SharpZipLib is approximately 20K lines.
public static class Compression
{
public static Byte[] CompressBytes(Byte[] input);
public static Byte[] CompressBytes(Byte[] input, Format format);
public static Byte[] CompressBytes(Byte[] input, Format format, Level level);
public static Byte[] DecompressBytes(Byte[] input);
public static Byte[] DecompressBytes(Byte[] input, Format format);
public static String CompressString(String input);
public static String CompressString(String input, Format format);
public static String CompressString(String input, Format format, Level level);
public static String DecompressString(String input);
public static String DecompressString(String input, Format format);
public static void CompressFile(String input_file_path, String output_file_path);
public static void CompressFile(String input_file_path, String output_file_path, Format format);
public static void CompressFile(String input_file_path, String output_file_path, Format format, Level level);
public static void DecompressFile(String input_file_path, String output_file_path);
public static void DecompressFile(String input_file_path, String output_file_path, Format format);
public static void CompressFolder(String input_folder_path, String output_file_path);
public static void CompressFolder(String input_folder_path, String output_file_path, Format format);
public static void CompressFolder(String input_folder_path, String output_file_path, Format format, Level level);
public static void DecompressFolder(String input_file_path, String output_file_path);
public static void DecompressFolder(String input_file_path, String output_file_path, Format format);
}
I would recommend breaking this single class into several classes. Generally speaking, static utility classes break a lot of rules, not the least of which is Separation of Concerns. While yes, all of the methods in this class deal with compression, they are concerned with compressing different things. Some compress byte arrays, some compress strings, some compress files. I would break this single utility into multiple utilities:
The above utility classes reduce repetition, better encapsulate purpose, are more cohesive with their member methods, and are clearer in intent. You do have four static utility types rather than one, but you aren’t breaking as many rules/best practices this way. Try to avoid monolithic, do-everything utility classes. If you can, find a way to make them instance classes rather than static classes, especially if there is any shared data at the class level that is used across each compress/decompress method. That will improve thread safety.
EDIT:
A more ideal implementation would use extension methods, as andy commented. The File and Folder compression are a bit more difficult to implement as extensions, but I’ve tried my hand. The following examples better achieve what I was aiming for: separation of noun (or subject) from verb (or operation), providing a cleaner API that ultimately has less repetition, maintains separation of concerns, and is properly encapsulated.