Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am developing a project in C# and due to a design decision it is not possible to have a static class inherit another static class. But I have, in my opinion, a case where this would make sense.

I have a music player which is able to play music from many different music sources: local files, YouTube, SoundCloud, Jamendo, etc. I have currently one static class for each of these sources with static methods such as retrieving the top tracks, searching for tracks, etc.

Naturally, a lot of code is shared among all these classes so I wanted to refactor and put all common code into a more generic MusicSource class. But C# doesn't allow me to do that.

What would be the best practice here? I want to get rid of all my redundant code and make it easier to create new music sources.

share|improve this question
1  
Given that you have countless static classes already.. why are you now considering inheritance? Why not just add a another common static class and call that from the others? –  Simon Whitehead Jul 12 '13 at 8:41
    
Why do you think you need inheritance? Why can't you group the redundant code into a static class and call it from your Music Source static classes? –  user2313838 Jul 12 '13 at 13:23
add comment

3 Answers

up vote 10 down vote accepted

Those "music source" classes sound more like non-static classes which you happen to only want one instance of. They are two different things!

Here are some reasons why you might want to make them non-static:

  • If they have (or might eventually have) some internal state. e.g. Cached login credentials, or cached lists of the top 10 tracks. Stateful static classes are a bad idea! They are basically a poor implementation of a singleton.
  • If you're going to have a lot of music sources, you may well want to perform some actions on all of them. e.g. Find a particular track from any source. With static classes you're going to need a line for each class. If you've got non-static classes you can just loop over a collection of them.

There's a great answer here which gives more reasons and goes into more detail.

share|improve this answer
add comment

It is not possible to inherit static classes at all (at least in C#), regardless of any 'design decision'.

Perhaps your question needs rephrasing, but can you not use non-static classes like in this contrived and overly simple example;

abstract class MusicSource 
{  
    abstract MusicData LoadMusic(string source);

    protected string SomeCommonProperty { get; set; }
}

class JamendoSource : MusicSource 
{   
    override MusicData LoadMusic(string source)
    {
        // Jamendo-specific code
    }
}
share|improve this answer
    
By "design decision" I was referring to the decision by Mads Torgersen. –  Christoffer Brodd-Reijer Jul 18 '13 at 5:27
    
There's nothing todo whith his decisions. .NET does not support static inheritance... –  Frederik P. Jul 18 '13 at 6:07
add comment

Using static in this case is completely wrong. People tend to use static's way to often! Basicly you have 1 "MusicPlayer" with X-amount of implementation (youtube, ...) So the first thing that should pop up in ur head is inheritance.

They will all do the same, but abit different => Inheritance. You want your application to work with serveral kinds of Sources, without any need to adapt the application it self => Inheritance/Interface segregation.

Static classes can be usefull, but in this case I have a feeling that the Music classes are the core of ur application... Don't build ur core functionality in Static classes, since you remove: testability, maintainability, reusability, extensibility, ...

You say:

I want to get rid of all my redundant code and make it easier to create new music sources.

Here again, Inheritance is central...

In C#, whenever u use static classes forget about inheritance. The other way around, whenever u need inheritance, forget about static classes.

Why did u initialy made them static anyway?

if you want to have only one instance available, make it a singleton. If not, just make it non-static!

share|improve this answer
    
The reason why I made it static was because I want to access the class from anywhere and everywhere without having to pass around the object to every constructor. Also, I only had a single source from the beginning so that's why inheritance was not obvious for me at the time I created the first class. –  Christoffer Brodd-Reijer Jul 18 '13 at 5:25
    
Thats why thinking about what u might need in the future is a good thing. "Do I want to support new sources in the future?". You say: "The reason why I made it static was because I want to access the class from anywhere and everywhere without having to pass around the object to every constructor" That is such a bad habit. It leads to extremely poor coding. In OOP u are supposed to pass around objects in this case. Static classes helps u to avoid this passing around, but breaks all the rest. Remove the statics, thats the first thing I advice u. PS:Statics can be good, but they're often misused. –  Frederik P. Jul 18 '13 at 6:06
    
Well I do plan on moving the classes over to a plugin system which would make them objects with inheritance. But I still don't see the benefits of not using static in this case. Passing around objects seems a lot messier as I need to change constructor and line of code creating the object, whenever I want to give a new object access to the class. Combined with the fact that only a single instance would be needed of the class, it seems more logical to use a static class. OOP principles be damned if breaking them is the more pragmatic approach. –  Christoffer Brodd-Reijer Jul 18 '13 at 7:00
    
Have u read the link Baqueta provided in his answer: stackoverflow.com/questions/241339/… ? It has a great set f-of answers! Passing around objects and creating instances should NOT be an issue when developing .NET applications. That "way" of thinking conflicts with the OOP way of working. –  Frederik P. Jul 18 '13 at 7:09
    
Yes, and only the point about testing caught my eye. The rest either don't apply or are avoidable with relative ease. But as I said, in this specific case it seems the best move is to move away from static classes and into a plugin system where each source is an instance of a plugin. But I'll still keep my static utility class. :) –  Christoffer Brodd-Reijer Jul 18 '13 at 7:22
show 4 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.