Can a low-level type depend on a high-level abstraction?

Question

Context:

This is for a library that reads some old games formats representing 3D models.

Let's call these low-level formats PRM1, PRM2, PRM3 and PRM4.

each of these formats contains the position, origin and primitives of a 3D model
they have minor implementation differences but in the end produce the same type of content
currently they all implement an IModel interface from which data is read to produce graphics

Now, I end up with duplicate methods in each of these types, they all do the same thing:

So I thought, why not ... ?

making a Model class that implements IModel directly, it would contain the whole mesh generation process since it's unique, effectively removing duplicate code
PRM1, PRM2, PRM3 and PRM4 would then derive from Model and they would only contain the reading from the binary file itself through the Model(Stream stream) constructor entry point

While this sounds the way to go, it feels weird as now low-level types depend on a high-level type.

Question:

Is this a perfectly valid approach/pattern or is there something I am missing ?

Have you considered splitting the data out into a separate 'POCO' model instead of storing the data in the same classes which contain the behaviour to read that data? — Ben Cottrell
– Ben Cottrell, Commented Jul 13, 2017 at 18:18
No, actually I adopted this solution since it was the simplest approach I came up with. — aybe
– aybe, Commented Jul 13, 2017 at 18:24

aybe · Accepted Answer · 2017-07-13 21:12:38Z

I just gave it a try and seems like it was a good move,

I stripped out many redundant code
locations where to look at are now reduced to a single one
concrete types only deal with the reading of data, base class does the transform
rendering didn't break
worked instantly
more generalization
etc ...

As a consequence I need some 'builders' to further abstract it but this is a good compromise IMO.

1 Answer 1