When designing input interfaces for a library, when to use data class rather than data interface?

Question

Let's say library A, B and C are all custom math libraries. They may or may not use the same data types. The libraries have methods that accept data type inputs like ProcessAsync(DataTypeA) or ClusterByFeature(IDataTypeB, Func<IDataTypeB, double>).

These libraries will be developed for modularity. E.g. Future graduate students can come and use the library for their needs.

I thought that these libraries should:

1. either provide concrete implementations of the inputs they accept and manipulate on, like DataTypeA, DataTypeB, DataTypeC
2. or, request that the users supply an object of type IDataTypeA, IDataTypeB, IDataTypeC

Which design I should choose seems to be dependent on many factors.

I've come up with a few:

• If it's just a container, it should be an interface
• If DataTypeA, DataTypeB, DataTypeC are all very similar, use interfaces - let the invoking framework supply the implementation by inheriting all the interfaces
• If DataTypeA requires complicated operations, use classes
• If DataTypeA requires simple operations, use interfaces and a DataTypeAManipulator class

I see other open-source libraries overwhelmingly use classes instead of interfaces, so I think classes should be the way to go. But is there no place for data interfaces then?

--

A better example of the problem that I faced: There's a 3D object that needs to be manipulated on. Library A handles vertices, Library B handles vertices and deformation by bone joints, Library C handles vertices and texture mapping. 3 different data objects - they're actually different views of a single data object, but the libraries don't/shouldn't know that! So should I use data interfaces to show different perspectives of a 3D object, or copy values to data classes instead.

Answer 1

Data classes make sense when they are used as a container for data (a POCO in .NET or POJO in Java). They contain no behaviour and simply serve to encapsulate data and simplify code, eg:

int CalculateSurface(int x1, int y1, int x2, int y2)

vs

int CalculateSurface(Rect area)

When you pass a data class, you could actually write the method so as to take the arguments separately. You obviously don't WANT to do that because it seriously clutters up your code, but you could.

A data interface makes sense when you actually need logic or behaviour, which means methods on the passed object need to be implemented. It also makes sense when you want the object you are working on to perform some operation and you need to pass it a parameter, in which case you need a contract for this method, hence an interface.