Reputation
Top tag
Next privilege 125 Rep.
Vote down
Badges
6
Newest
 Commentator
Impact
~376 people reached

  • 0 posts edited
  • 0 helpful flags
  • 8 votes cast
Oct
15
awarded  Commentator
Oct
15
comment When designing input interfaces for a library, when to use data class rather than data interface?
@JonathanvandeVeen Assuming the rules above still apply, then to avoid users from repurposing the data class beyond its original use, it can be marked as final/uninheritable. Or if you meant data interfaces with data and logic, then maybe 1 data object interface and 1 data manipulator interface.
Oct
15
awarded  Editor
Oct
15
revised When designing input interfaces for a library, when to use data class rather than data interface?
added 493 characters in body
Oct
15
comment When designing input interfaces for a library, when to use data class rather than data interface?
@CodesInChaos Ah I see its usefulness now. Let me give a better context then. 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.
Oct
15
comment When designing input interfaces for a library, when to use data class rather than data interface?
@CodesInChaos I don't understand the point of doing so.. Regardless of the library declaring data classes or data interfaces, what scenarios would generic constraints help in?
Oct
15
comment When designing input interfaces for a library, when to use data class rather than data interface?
And by extension, I suppose if it's just a data container, tuples/structs would work fine too as a data class..
Oct
15
comment When designing input interfaces for a library, when to use data class rather than data interface?
So by "when you actually need logic or behaviour", you're referring to behaviour that the user has to define, like IEnumerable.MoveNext() etc.? In other cases where the library knows how to perform this logic, I assume it's fine to still use a data class that has instance methods.
Oct
15
asked When designing input interfaces for a library, when to use data class rather than data interface?
Jul
13
awarded  Scholar
Jul
13
accepted Strategies to manage a modular C# framework
Jul
13
comment Strategies to manage a modular C# framework
The SOLID principles were very helpful! In the end I settled for a generic IAlgorithm interface with Run() and a generic IAlgoParam input. The middle layer is agnostic to it all, while the front-layer and back-layer knows which objects to supply or cast to.
Jul
12
awarded  Student
Jun
12
comment Strategies to manage a modular C# framework
@Ewan For models yes, a single datalayer project is enough. But each algorithm is also in its own project, and to compile any algorithm at all, even if only 1 algorithm, the datalayer project is required. That's the part I had difficulty accepting.
Jun
12
comment Strategies to manage a modular C# framework
@DocBrown Yea... I may have to rethink how much unused code I should allow.
Jun
12
comment Strategies to manage a modular C# framework
But on 2nd thought... that is true for most 3rd party libs. There's a lot of unused code inside.. (e.g. Boost)
Jun
12
comment Strategies to manage a modular C# framework
All of the shared data structures are packaged under the CommonInterfaces.dll, however each algorithm only uses a small subset of it. So if a particular algorithm isn't used, including the .dll would pull in lots of code that is never executed as well.
Jun
12
asked Strategies to manage a modular C# framework
Jul
7
awarded  Supporter
Nov
26
awarded  Autobiographer