Is a huge class ok for the sake of simplicity?

I'm working on a movie playback related app and I'm running into some design issues at the moment.

As you would expect, I have a movie class with properties for things like the file path, file size and others. The movie class does not know anything about the movie internals and it doesn't decode the movie file directly.

To achieve that, I have another large class: the decoder. This class knows all movie internals like the duration, the frame rate etc. It also offers methods to retrieve video or audio data from the file. Breaking up the decoder into smaller chunks would not make much sense as the decoder uses a third party library and a lot of C pointers would need to be handed around. I'd rather avoid that for the sake of simplicity regarding memory management etc.

A movie holds a decoder with a clearly defined interface as the decoder itself is implemented using the strategy pattern in my movie class.

                  Movie      ---------------->     Decoder (implements interface)
                    |                                  |
                    v                                  v
           File related variables                 Movie internals

I'm wondering if this design is good in terms of information hiding and SRP. All outside classes know that a movie has a decoder with a bunch of properties. Wouldn't it be better to have them only know that there's a movie? But then the movie class would get enormous and there would be a lot of stub methods only accessing the decoder's properties.

Any advice would be appreciated.

Edit:

I took a deeper look at the Facade pattern (inspired by @Erik's answer) and it looks like the perfect match here. I can subdivide the Movie class a bit further but the "outside world" shouldn't need to know about the details to avoid complexity. However, this will yield a Facade class with lots of methods.

Thus, it looks like it is a huge class from the outside while it's nicely separated into logical bricks when looking on the inside. Do you think it is ok then?

Solution

Rather than pulling all the code into a new class, you could make a new class that itself contains no logic, but simply wraps around a Movie and exposes a large collection of methods that each call the neccesary methods on Movie and Decoder.

This is basically an implementation of the Facade Pattern:

https://en.wikipedia.org/wiki/Facade_pattern

It has the advantage that outside classes have no knowledge about how a movie works other than "it's this class with all these properties we can ask for", while on the inside you don't end up with huge classes.