What is better - polymorphism or inheritance as a concept for operating with a .net library?

Question

If I create a library with most functions meant for overwriting, meaning that you will need to put your logic into some of initial library functions to get what you want from library. will it be normal\usual\OK? will such library be called a framework?

Example In my library I have CreateData function, lots of other functions and one, lets call it Main function, which uses lots of functions in library, has understandable logic and is just grate to receive some result you want to in a wary fast way. Only thing is that it uses CreateData function too. so you can just call Main and get some result on some random\pregenerated by library creator data, but when you will want, not implementing Main on your own, just change logic of data creation you should overwrite CreateData function.

Is such way OK from OOP point of view or I should re-write Main using polymorphism?

But If I will start to use polymorphism I'd probably will need to use it to all 20-50 functions I have in use in main which now are just over-writable...

Answer 1

I'd say "none of the above - composition is generally best."

Polymorphism implies inheritance. In general you're overriding virtual methods when you're setting up polymorphic behavior.

It sounds like what you're doing is the Template Method Pattern.

I would strongly suggest writing unit tests for your library (or framework; the terms are often interchangeable). This will force you to use your own code from the perspective of a client developer (the technical term is "dogfooding"). That technique helps to find pain points.

I'd also recommend reading Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition) and running its companion tool, FxCop. You'll learn best practices from the experts.