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.

This question already has an answer here:

I'm starting a game project in C++ using the SFML.

It provides various classes for handling graphics, input, etc, but I would like to wrap it all up in a single Media class.

I believe that by doing so, I could simplify my effort and have the class take care of the details, limiting the amount of code I have to write and therefor limiting chances for a bug to sneak past my eyes.

However, I have read several times that monolithic, do-it-all classes such as this might not be a good idea.

Why is that?

share|improve this question
    
possible duplicate of How many are too many interfaces on a class? –  gnat Feb 10 '13 at 10:46
add comment

marked as duplicate by gnat, ChrisF Feb 10 '13 at 12:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

up vote 1 down vote accepted

Would it be bad design to abstract a graphics library and wrap it in a single class?

The answer is: Not necessarily! But in your case: Probably!

I guess what you are trying to do also has a name: It's called the facade pattern and is used to simplify complex routines and sequential dependencies for the user.

It provides various classes for handling graphics, input, etc, but I would like to wrap it all up in a single Media class.

I smell bad OO Design here because you give a class multiple responsibilities. Input Handling should not share code with the graphics routines. This class could very well add up to something unmaintainable eventually.

However, I have read several times that monolithic, do-it-all classes such as this might not be a good idea.

Why is that?

It's all about maintainability. You're coupling things which do not belong together, and every part of your system that uses it then has a strong coupling to these things as well. Let me give you a quick example of code I saw recently:

//bad! This is in a data access class! I have effectively coupled it to web libraries by using HttpServletRequest
public List<Reason> getReasons(HttpServletRequest request, String filter) {
    Locale locale = request.getLocale();
    //get reasons and process according to locale
}

//much much better: No coupling/dependencies to web environment
public List<Reason> getReasons(Locale locale, String filter) {
    //get reasons and process according to locale
}

Think about this example: If I'd use that class in Desktop-Application, I'd still have all the web stuff in there, just because someone decided to use HttpServletRequest. It'd be an unecessary dependency.

You might ask how this is directly related to your question, and the answer is: It's all about dependencies/coupling. The more dependencies, the stronger your couplings, the harder your code will be to reuse or to enhance or to maintain without carrying around a lot of garbage or using ugly hacks.

share|improve this answer
    
Hm, I ended up not creating a Media class, but a Game class. It basically uses various other classes (World, Window/Graphics, etc) to make a game. I don't think there's a problem though: instead of creating a main function I simply delegated all of that into a class, which is simply instantiated by main. It isn't really "used" by anything at all, it's like the Main class in Java. –  akled Feb 10 '13 at 16:17
add comment

Because any time you have to change anything, you'll find it has impacts on everything. In addition, one class can only have one lifetime, whereas in reality you want to have several lifetimes for several different components- for example, you want each sprite to live a different length of time.

share|improve this answer
add comment

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