Return to Answer

I think you have two problems closely related to each other.

• Static classes contains logically unrelated functions
• Names of static classes do not provide helpful information about meaning/context of the contained functions.

These problems can be fixed by combining only logically related methods into one static class and moving the others into their own static class. Based on your problem domain, you and your team should decide what criteria you will use for separating methods into related static classes.

###Concerns and possible solutions

Methods are mostly unrelated to each other - problem. Combine related methods under one static class and move unrelated methods to their own static classes.

Methods are without explicit state persisted across invocations - not a problem. Stateless methods are a feature, not a bug. Static state is difficult to test anyway, and should only be used if you need to maintain state across method invocations, but there are better ways to do that such as state machines and the yield keyword.

Methods are small - not a problem. - Methods should be small.

Methods are each consumed by a variety of unrelated types - not a problem. You have created a general method which can be re-used in many not related places.

A static class is being used solely as a namespace - not a problem. This is how static methods are used. If this style of calling methods bothers you, try using extension methods or the using static declaration.

The static class identifier is basically meaningless - problem. It is meaningless because developers are putting unrelated methods in it. Put unrelated methods into their own static classes and give them specific and understandable names.

When a new GLUM gets added, either (a) this "bag" class gets touched (SRP sadness) - not a problem if you follow idea that only logically related methods should be in one static class. SRP is not violated here, because principle should be applied for classes or for methods. Single responsibility of static classes means to contain different methods for one general "idea". That idea can be a feature or a conversion, or iterations(LINQ), or data normalization, or validation ...

or less frequently (b) a new "bag" class gets created (more bags) - not a problem. Classes/static classes/functions - are our(developers) tools, which we use for designing software. Does your team have some limits for using classes? What are maximum limits for "more bags"? Programming is all about context, if for solution in your particular context you end up with 200 static classes which understandably named, logically placed in namespaces/folders with logical hierarchy - it is not a problem.

The meta-naming is inescapably awful, non-standard, and usually internally inconsistent, whether it's Helpers, Utilities, or whatever - problem. Provide better names that describe expected behaviour. Keep only related methods in one class, which provide help in better naming.

I think you have two problems closely related to each other.

• Static classes contains logically unrelated functions
• Names of static classes do not provide helpful information about meaning/context of the contained functions.

These problems can be fixed by combining only logically related methods into one static class and moving the others into their own static class. Based on your problem domain, you and your team should decide what criteria you will use for separating methods into related static classes.

Concerns and possible solutions

Methods are mostly unrelated to each other - problem. Combine related methods under one static class and move unrelated methods to their own static classes.

Methods are without explicit state persisted across invocations - not a problem. Stateless methods are a feature, not a bug. Static state is difficult to test anyway, and should only be used if you need to maintain state across method invocations, but there are better ways to do that such as state machines and the yield keyword.

Methods are small - not a problem. - Methods should be small.

Methods are each consumed by a variety of unrelated types - not a problem. You have created a general method which can be re-used in many not related places.

A static class is being used solely as a namespace - not a problem. This is how static methods are used. If this style of calling methods bothers you, try using extension methods or the using static declaration.

The static class identifier is basically meaningless - problem. It is meaningless because developers are putting unrelated methods in it. Put unrelated methods into their own static classes and give them specific and understandable names.

When a new GLUM gets added, either (a) this "bag" class gets touched (SRP sadness) - not a problem if you follow idea that only logically related methods should be in one static class. SRP is not violated here, because principle should be applied for classes or for methods. Single responsibility of static classes means to contain different methods for one general "idea". That idea can be a feature or a conversion, or iterations(LINQ), or data normalization, or validation ...

or less frequently (b) a new "bag" class gets created (more bags) - not a problem. Classes/static classes/functions - are our(developers) tools, which we use for designing software. Does your team have some limits for using classes? What are maximum limits for "more bags"? Programming is all about context, if for solution in your particular context you end up with 200 static classes which understandably named, logically placed in namespaces/folders with logical hierarchy - it is not a problem.

The meta-naming is inescapably awful, non-standard, and usually internally inconsistent, whether it's Helpers, Utilities, or whatever - problem. Provide better names that describe expected behaviour. Keep only related methods in one class, which provide help in better naming.

I think you have two problems closely related to each other.

• Static classes contains logically unrelated functions
• Names of static classes do not provide helpful information about meaning/context of the contained functions.

These problems can be fixed by combining only logically related methods into one static class and moving the others into their own static class. Based on your problem domain, you and your team should decide what criteria you will use for separating methods into related static classes.

###Concerns and possible solutions

Methods are mostly unrelated to each other - problem. Combine related methods under one static class and move unrelated methods to their own static classes.

Methods are without explicit state persisted across invocations - not a problem. Stateless methods are a feature, not a bug. Static state is difficult to test anyway, and should only be used if you need to maintain state across method invocations, but there are better ways to do that such as state machines and the yield keyword.

Methods are small - not a problem. - Methods should be small.

Methods are each consumed by a variety of unrelated types - not a problem. You have created a general method which can be re-used in many not related places.

A static class is being used solely as a namespace - not a problem. This is how static methods are used. If this style of calling methods bothers you, try using extension methods or the using static declaration.

The static class identifier is basically meaningless - problem. It is meaningless because developers are putting unrelated methods in it. Put unrelated methods into their own static classes and give them specific and understandable names.

When a new GLUM gets added, either (a) this "bag" class gets touched (SRP sadness) - not a problem if you follow idea that only logically related methods should be in one static class. SRP is not violated here, because principle should be applied for classes or for methods. Single responsibility of static classes means to contain different methods for one general "idea". That idea can be a feature or a conversion, or iterations(LINQ), or data normalization, or validation ...

or less frequently (b) a new "bag" class gets created (more bags) - not a problem. Classes/static classes/functions - are our(developers) tools, which we use for designing software. Does your team have some limits for using classes? What are maximum limits for "more bags"? Programming is all about context, if for solution in your particular context you end up with 200 static classes which understandably named, logically placed in namespaces/folders with logical hierarchy - it is not a problem.

The meta-naming is inescapably awful, non-standard, and usually internally inconsistent, whether it's Helpers, Utilities, or whatever - problem. Provide better names that describe expected behaviour. Keep only related methods in one class, which provide help in better naming.

From an automating testing point of view - if static functions contain complicated logic which is used by different consumers/classes, you probably should introduce an abstraction(interface) where it's implementation will contain those methods. Abstraction give you possibility to not test this logic multiple times through it's consumers. In consumer's unit tests you will be able to mock up logic and concentrate testing on the actual logic.

I think you have two problems closely related to each other.

• Static classes contains logically unrelated functions
• Names of static classes do not provide helpful information about meaning/context of the contained functions.

These problems can be fixed by combining only logically related methods into one static class and moving the others into their own static class. Based on your problem domain, you and your team should decide what criteria you will use for separating methods into related static classes.

###Concerns and possible solutions

Methods are mostly unrelated to each other - problem. Combine related methods under one static class and move unrelated methods to their own static classes.

Methods are without explicit state persisted across invocations - not a problem. Stateless methods are a feature, not a bug. Static state is difficult to test anyway, and should only be used if you need to maintain state across method invocations, but there are better ways to do that such as state machines and the yield keyword.

Methods are small - not a problem. - Methods should be small.

Methods are each consumed by a variety of unrelated types - not a problem. You have created a general method which can be re-used in many not related places.

A static class is being used solely as a namespace - not a problem. This is how static methods are used. If this style of calling methods bothers you, try using extension methods or the using static declaration.

The static class identifier is basically meaningless - problem. It is meaningless because developers are putting unrelated methods in it. Put unrelated methods into their own static classes and give them specific and understandable names.

When a new GLUM gets added, either (a) this "bag" class gets touched (SRP sadness) - not a problem if you follow idea that only logically related methods should be in one static class. SRP is not violated here, because principle should be applied for classes or for methods. Single responsibility of static classes means to contain different methods for one general "idea". That idea can be a feature or a conversion, or iterations(LINQ), or data normalization, or validation ...

or less frequently (b) a new "bag" class gets created (more bags) - not a problem. Classes/static classes/functions - are our(developers) tools, which we use for designing software. Does your team have some limits for using classes? What are maximum limits for "more bags"? Programming is all about context, if for solution in your particular context you end up with 200 static classes which understandably named, logically placed in namespaces/folders with logical hierarchy - it is not a problem.

The meta-naming is inescapably awful, non-standard, and usually internally inconsistent, whether it's Helpers, Utilities, or whatever - problem. Provide better names that describe expected behaviour. Keep only related methods in one class, which provide help in better naming.

I think you have two problems closely related to each other.

• Static classes contains logically unrelated functions
• Names of static classes do not provide helpful information about meaning/context of the contained functions.

These problems can be fixed by combining only logically related methods into one static class and moving the others into their own static class. Based on your problem domain, you and your team should decide what criteria you will use for separating methods into related static classes.

###Concerns and possible solutions

Methods are mostly unrelated to each other - problem. Combine related methods under one static class and move unrelated methods to their own static classes.

Methods are without explicit state persisted across invocations - not a problem. Stateless methods are a feature, not a bug. Static state is difficult to test anyway, and should only be used if you need to maintain state across method invocations, but there are better ways to do that such as state machines and the yield keyword.

Methods are small - not a problem. - Methods should be small.

Methods are each consumed by a variety of unrelated types - not a problem. You have created a general method which can be re-used in many not related places.

A static class is being used solely as a namespace - not a problem. This is how static methods are used. If this style bothers you, try using extension methods or the using static declaration.

The static class identifier is basically meaningless - problem. It is meaningless because developers are putting unrelated methods in it. Put unrelated methods into their own static classes and give them specific and understandable names.

When a new GLUM gets added, either (a) this "bag" class gets touched (SRP sadness) - not a problem if you follow idea that only logically related methods should be in one static class. SRP is not violated here, because principle should be applied for classes or for methods. Single responsibility of static classes means to contain different methods for one general "idea". That idea can be a feature or a conversion, or iterations(LINQ), or data normalization, or validation ...

or less frequently (b) a new "bag" class gets created (more bags) - not a problem. Classes/static classes/functions - are our(developers) tools, which we use for designing software. Does your team have some limits for using classes? What are maximum limits for "more bags"? Programming is all about context, if for solution in your particular context you end up with 200 static classes which understandably named, logically placed in namespaces/folders with logical hierarchy - it is not a problem.

The meta-naming is inescapably awful, non-standard, and usually internally inconsistent, whether it's Helpers, Utilities, or whatever - problem. Provide better names that describe expected behaviour. Keep only related methods in one class, which provide help in better naming.

From an automating testing point of view - if static functions contain complicated logic which is used by different consumers/classes, you probably should introduce an abstraction(interface) where it's implementation will contain those methods. Abstraction give you possibility to not test this logic multiple times through it's consumers. In consumer's unit tests you will be able to mock up logic and concentrate testing on the actual logic.

I think you have two problems closely related to each other.

• Static classes contains logically unrelated functions
• Names of static classes do not provide helpful information about meaning/context of the contained functions.

These problems can be fixed by combining only logically related methods into one static class and moving the others into their own static class. Based on your problem domain, you and your team should decide what criteria you will use for separating methods into related static classes.

###Concerns and possible solutions

Methods are mostly unrelated to each other - problem. Combine related methods under one static class and move unrelated methods to their own static classes.

Methods are without explicit state persisted across invocations - not a problem. Stateless methods are a feature, not a bug. Static state is difficult to test anyway, and should only be used if you need to maintain state across method invocations, but there are better ways to do that such as state machines and the yield keyword.

Methods are small - not a problem. - Methods should be small.

Methods are each consumed by a variety of unrelated types - not a problem. You have created a general method which can be re-used in many not related places.

A static class is being used solely as a namespace - not a problem. This is how static methods are used. If this style of calling methods bothers you, try using extension methods or the using static declaration.

The static class identifier is basically meaningless - problem. It is meaningless because developers are putting unrelated methods in it. Put unrelated methods into their own static classes and give them specific and understandable names.

When a new GLUM gets added, either (a) this "bag" class gets touched (SRP sadness) - not a problem if you follow idea that only logically related methods should be in one static class. SRP is not violated here, because principle should be applied for classes or for methods. Single responsibility of static classes means to contain different methods for one general "idea". That idea can be a feature or a conversion, or iterations(LINQ), or data normalization, or validation ...

or less frequently (b) a new "bag" class gets created (more bags) - not a problem. Classes/static classes/functions - are our(developers) tools, which we use for designing software. Does your team have some limits for using classes? What are maximum limits for "more bags"? Programming is all about context, if for solution in your particular context you end up with 200 static classes which understandably named, logically placed in namespaces/folders with logical hierarchy - it is not a problem.

The meta-naming is inescapably awful, non-standard, and usually internally inconsistent, whether it's Helpers, Utilities, or whatever - problem. Provide better names that describe expected behaviour. Keep only related methods in one class, which provide help in better naming.

From an automating testing point of view - if static functions contain complicated logic which is used by different consumers/classes, you probably should introduce an abstraction(interface) where it's implementation will contain those methods. Abstraction give you possibility to not test this logic multiple times through it's consumers. In consumer's unit tests you will be able to mock up logic and concentrate testing on the actual logic.