6

I'm currently reading about Java best practices and I found that according to this book we must Favor static classes over nonstatic. I've remembered that in C# best practices we must avoid such according to Coding Guidelines for C# 3.0, 4.0 and 5.0 by Dennis Doomen:

AV1008 - Avoid static classes

With the exception of extension method containers static classes very often lead to badly designed code. They are also very difficult, if not impossible, to test in isolation unless you’re willing to use some very hacky tools. Note If you really need that static class, mark it as static so that the compiler can prevent instance members and instantiating your class. This relieves you of creating an explicit private constructor.

I found these two for C# answer and Java answer when to use and avoid static classes, but just by curiosity - both C# and Java are OOP languages, why it's this complete difference then in best practices?

Update: I can't copy so much pages here from the Java book, but bottom line is:

If you declare a member class that does not require access to an enclosing instance, always put the static modifier in its declaration, making it a static rather than a nonstatic member class. If you omit this modifier, each instance will have an extraneous reference to its enclosing instance. Storing this reference costs time and space, and can result in the enclosing instance being retained when it would otherwise be eligible for garbage collection (Item 6). And should you ever need to allocate an instance without an enclosing instance, you’ll be unable to do so, as nonstatic member class instances are required to have an enclosing instance. A common use of private static member classes is to represent components of the object represented by their enclosing class.

So is it about performance only?

Please note that this question is more about Static classes and OOP, not difeerences between Java and C#.

Community
  • 1
  • 1
ekostadinov
  • 6,880
  • 3
  • 29
  • 47
  • Does the author of that book give a reason for why we should *favor static classes over nonstatic*? – Dirk Sep 02 '14 at 06:43
  • 1
    I've been wondering this about Python too.. Pycharm (an ide for python) has riddled my code with warnings that methods can be made static and it drives me crazy – Sayse Sep 02 '14 at 06:44
  • 2
    Not the correct forum for this type of question. – Robert Langdon Sep 02 '14 at 06:44
  • 2
    I think you are missing context from the book, you would have to give excerpt form book to judge. – Mateusz Sep 02 '14 at 06:44
  • Bad practices I know there are, but best, I'm not so sure.. – TaW Sep 02 '14 at 06:59
  • 3
    There is a fundamental difference between static classes in C# and Java, although they use the same keyword, they are **not the same** concept. – Mark Rotteveel Sep 02 '14 at 07:29

2 Answers2

9

Advice given by JoshuaBloch also applies for c# and advice given for c# also applies for java(upto an extent as they talk about static classes).

Why use static members?

  • They don't need an instance to call them
  • In c# they use call opcode, which doesn't needs to check for null(which is a micro optimization) as opposed to instance methods(which uses callvirt opcode). I believe similar thing will be there in java also.
  • They don't prevent something from GC if instance is not used.
  • Also no overhead of passing this reference to all the methods hidden.

If you are used to Resharper productivity tool for visual studio, It will give the same advice as JoshuaBloch given for java, in c# saying that Method can be made static which is justified in the given link.

Why not use static members?

  • They are not testable(easily).
  • They can't implement interface member.
  • They can't be injected via Dependency Injection.
  • They don't participate in polymorphism (which is very much needed in object oriented languages).
  • In c#, static classes can't be passed around as references.

So, both advices are good if you understand them and they apply for both the languages. Use them when they are appropriate and avoid them when they are not.

Sriram Sakthivel
  • 72,067
  • 7
  • 111
  • 189
  • Its better to use Static classes instead of singletons. Most static classes can be made thread safe too. – Aniket Inge Sep 02 '14 at 07:31
  • @Aniket I don't get it. Why so? Static doesn't makes inherently thread safe. We need to pay for thread safety. Also singleton classes must be thread safe. – Sriram Sakthivel Sep 02 '14 at 07:32
  • Can be.. not that they ARE by default – Aniket Inge Sep 02 '14 at 07:33
  • I was meaning to say that they can be made threadsafe singletons. – Aniket Inge Sep 02 '14 at 07:33
  • @Aniket, oh really? Classic singleton implementation is transparent for class client, static - not. As soon as you make some class static you refuse all OOP benefits, because at least (!) static class can not be derived or inherited. – Valentin P. Sep 02 '14 at 07:45
  • And also static fields potentially can lead to memory leaks. If one forgot to set static field value to null, than GC cannot collect associated objects graph - static fields never exempts by GC. – Valentin P. Sep 02 '14 at 08:17
3
  1. I consider that second text fragment is all about member class and enclosing, which is Java-specific feature (how it is implemented).
  2. Static class or field (as in C#) is actually bad design practice - take a look at OOP and SOLID. In addition it can result in some performance issues on CLR level. But it's nothing wrong with private static method. As I remember, Resharper advices to make private methods independent on concrete instances static. It increases readability and has no side-effects. And you not need to unit test private method. It's bad practice too.
  3. Finally, some authors write about technologies in nutshell and some - about design principles. Often there is a contradiction between these points of view (but depicted two fragments is not about it).
Valentin P.
  • 1,131
  • 9
  • 18