Question

i have something like this in my project, the project it’s kinda finished already (it’s working)
i just want know if it is ok with the SOLID principles

static public class Tools
{
    static public GetProduct(this id){...}

    static public GetProductCategory(this id){...}

    static public GetUser(this id){...}

    // I also have here methods like IsStringNull ...
    // IsNull IsFalse, lots of stuff, everything static
}

and the usage is like this

var UserThatCreatedCategoryForThisProduct = 
      prodId.GetProduct().CategoryId.GetProductCategory().Creator.GetUser();

i know that is obvious that it’s violates the SRP, but this class is static and it contains static methods that are independent one from each other, and it’s kind off the same if i would create a static class for each method

Answer 1

Far as I can see, there are a lot of SOLID violations right here!

• Violations of Single Responsibility Principle – First you have data access methods for several classes, second you have helper methods (IsStringNull, IsNull, etc) intertwined with them.
• Violations of Interface Segragation Principle (as mentioned by Ruben) – If I were only concerned for Products, why do I need exposure to methods that get Users?

I’m sure there are some others, but these are the glaring ones.

UPDATE Now that someone commented on it, I think they’re right; the code above looks like it’s some form of extension method abuse.

For example I don’t believe Data Access should be relegated to extension methods, or worse, a class named “Tools”.

It’d probably make more sense to have a base class (on a totally different namespace and/or assembly) that abstracts your data access generalities, then inherit one data access class for each unique domain object (e.g., UserDAO, ProductDAO, etc). Do understand that my assumption here is that by GetProduct or GetUser you actually mean GetFromDatabase.

The rest of the helper methods do belong to extensions so they’re fine.