Is using multiple static classes with maximum one public method is a good idea

Question

I'm writing a structural detailing (CAD) software for concrete buildings in C#. I have defined like hundreds of static classes each with one public method and if needed some private methods. Each one of these methods in these static classes does part of the job. They are called from one God static class named Building.cs.

For example one class looks like this:

public static partial class GetMainRebars
{
    public static void GetMainRebars()
    {
    }

    // other possible variables and private methods
}

The program is running very very fast compared to other similar programs. But deep in my heart, looking at the above code I feel that something still may be wrong with this design pattern. Maybe I will encounter problems in terms of maintenance, or ...? I've taught myself programming, so I may have missed many core principles during the fast self teaching process. Can you elaborate the cons and pros of the above pattern?

And one very rookie question relevant to the pattern. Let's say I define a static variable inside such a class, will it remain in memory during the life time of the program? No disposing and whatsoever? Is it OK?

Update: When the program starts I'm loading the required variables in relevant fields and properties in the Building.cs for example listOfBeams, listOfColumns, listOfRebars, listOfConnectivities and etc. Now that these variables are in place, I used the methods in static classes to do various operations on these. Let's say I get the listOfRebars and listOfColumns in one static class and generate some variables to output. Then I get listOfRebars and listOfBeams and do some other stuff.

Update2: From what I have learned based on the answers and comments, I have come up with the below pattern. I was wondering if I'm on the right path?

I have one static class: Building.cs When I create/or load a project this class holds all the properties of the building like list of columns, beams, points, etc. All of these are stored as private fields. I can access these using the class's public methods like GetColumns or GetPoints ...

Now I also have non-static classes. They contain 2-3 public methods. and do some stuff on various parts of the building.

public static class Building
{
    private static List<Column> columns;
    private static List<Beams> beams;
    private static List<Points> points;

    public static List<Column> GetColumns() 
    {
        return Columns;
    }
}

public class ColumnsService()
{
    private List<Columns> columns;
    public GroupColumns(List<Columns> columns)
    {
        this.columns = columns;
    }

    public void Group()
    {
        // group columns
    }
}

var columns = Building.GetColumns();
var columnsService = new ColumnsService(columns);
columnsService.Group();

Answer 1

Using static classes like this is simple and efficient. Like most things that are simple and efficient it comes with drawbacks:

• your code will be difficult to unit test because any object that uses these static methods cannot easily be separated from them, so tests will have to include them, whereas usually we'd aim to use either stub or mock implementations of the collaborators of the object being tested.

• it increases coupling, which has the effect of making your code hard to change.

• it leads to needing large amounts of global state, which in itself also leads to testing being hard (global state can make tests dependent on each other, which is undesirable) and making changes harder (global state can lead to hard-to-identify interactions between apparently unrelated areas of the program)

The best approach would be to change the objects to non-static and use dependency injection to manage the dependencies between objects.

Answer 2

I am not familiar with C#, but it is my conviction that one should try to limit global values and classes as programming in general. Of course depending on the sircumstances. Always try and keep your classes to a minmum (but logical) responsibility. You should do some reading on the subject "low coupling high cohesion".

If you have a lot of classes interacting or depending on eachother, maybe you could implement a mediator design pattern or a observer pattern.

But it could sound to me that you haven't spent time doing some design of your project. We can give a better answer to your question, if you could provide us with an explanation of the domain or how the objects relates/should relate to eachoter.