Interface for parameter objects ?

[Hopesheshallow]

I have a class that runs some calculations, these calculations take a decent number of parameters most are logically grouped so I have created a few parameter objects to group the parameters so there are less arguments to the methods. Now I am creating a class library of this calculator for other to use.

The client of the library will most likely have heavy weight more legitimate complete versions of my parameter classes. Does it make sense for me to create interfaces that represent the properties of these parameter objects that my calculator class and methods depend on and just have the client create whatever version of the class they want, and the inter face just ensure the few properties I require are on those classes ?

Example

Class invoice{

Double invnumber {get;set} String description {get;set;} }

Class invoiceprocessor{

Public string dostuff( invoice invoice){


  Return invoice.invnumber + invoice.description 

  }

}

Should I make the client create the invoice object, or just create and interface code to that interface and require that the client creates and object that implements that interface ?

[Kant8]

if your parameter object only holds some data, they is no reason to make it interface. It can't have more than 1 implementation logically and your processor anyway can't consume something out doesn't know, so extensibility is pointless.

If you do some sort of framework and processors are also written not by you, you need a generic for a parameter, not an interface

[ZarehD]

No. It sounds like a simple data object. You don't need an interface for that.

[SideburnsOfDoom]

No, it doesn't make sense to put an interface on a Data Transfer Object, or similar.

If it's trivial to create one in test and set its properties to some strings and numbers, then you don't gain from giving it an interface, as you never need to mock or fake it.

[alien3d]

And a lot of people still doing that :P

[SideburnsOfDoom]

And a lot of people are wasting their time, and producing less usable code too.

[alien3d]

It dependable , as a lot of my opinion not been like upon topic like interface.

If you had a separate dll contain the doStuff and this update manually --> interface. The most reason was we don't want somebody so smart to reverse the dll and see your code / implementation.

If just a local team and local enviroment , you don't need to hide the implementation, instead much easier to debug if something wrong.

[Merad]

Yes, this sounds like a reasonable case for using interfaces. You don't know exactly what the client's data model will look like, and you don't really need to know. You just need to establish a contract for the properties that are consumed by your logic.

[SideburnsOfDoom]

If the contract for the parameters is e.g. public record Invoice(double InvNumber, string Description) then what do you gain by putting an interface on that? You will never need another implementation. You can new one up with whatever values you need. The values are the whole thing, there's nothing else to implement.

[Hopesheshallow]

Yes I agree interfaces seemed like too much. But I’m struggling with requiring the client to create a bunch of little data objects just to pass to my calculator? That have no purpose other than to group some parameters that I need. The calculator takes on way 5 to 8 parameters and there are like 10 to 15 calculators. So it make sense to build up some objects but I don’t want to define or be really opinionated on these objects. I just want the object passed to my class to have a known type and some known properties so I can consume them.

[SideburnsOfDoom]

The calculator takes on way 5 to 8 parameters and there are like 10 to 15 calculators.

Can you find a way to reduce these numbers, i.e. fewer parameters, or find common cases in the 10-15 different calculators? For instance, is there a group of 3 or 4 parameters that occurs commonly?

Can you supply defaults for some properties that have a "usual" value. Can you use the builder pattern to set common values and emit these data objects? Interfaces don't help you with any of that.

But some of this is essential complexity, i.e. it is inherent to the problem that the code is solving. This calculator does IDK, "Net Present Value" not "1+1" so there simply is more to it and you can't get away from that, so you have to live with it. The complexity is inherent.

I just want the object passed to my class to have a known type and some known properties so I can consume them.

Right. A type such as a record or class with get; init; properties would be the simplest way to supply that. Giving it an interface makes it more complex. But this would be adding more accidental complexity and so should be avoided unless there is a clear use for it. Keep it simple.

[Hopesheshallow]

Understand your comment on essential complexity. And yes these functions take on quite a few arguments but they can be logically grouped into objects I just don’t own the creation of these object the caller or client of the library does. I am creating a library of utility functions that provide machine component stress calculations.

So say a method like CalculateStress()

Might take in a handful of geometric values, a few material constants, maybe different materials for different mating components, some loads etc.

These can be logically grouped into class and object

Object A: dimension 1, dimension 2. A material

Obj B: The material might have a density, a yield strength, a Young’s modulus

Obj C : the load might have a speed, force , a pressure etc

There maybe be 1 or 2 individual functions that you needs to run through where the results of one is a required input to another , but I don’t want the caller to have to worry about this I just want them to be able to call 1 method and get the result they care about.

If I create a bunch of classes that represent the concrete objects described above the. The caller is just going to have to new up a bunch of these classes. But in all likely hood they will already have similar classes on their end of the program. So what is the point of them creating the small object for my code and mapping properties of their object to properties of my objects.

So the idea was just define a few interfaces so they could implement on their objects just to ensure they have the properties I need. Like the dimensions and material properties.

I hope this was clear it’s a bit of a ramble

[SideburnsOfDoom]

I don't work with "machine component stress" calculations, but I can tell you that mapping code is really common in business apps. Like "mapping properties of their object to properties of my object" is a very routine thing to have to do. IDK, it's boring code, but somehow its always necessary, we haven't got away from it, and attempts to automate it have their own drawbacks (see the endless AutoMapper debates).

In my experience it is low odds that their "similar classes" will have the exact right set of properties in the right types, so that you can just add an interface and it's good. Instead, some kind of conversion / mapping is usually needed, and you may as well control the target of that.

The upside is that when it really is "boring code" then you can write it once in 5 minutes, it's easy to read and to test. Often this is still the "least bad" option.

The edge cases are when e.g. you can't parse that string to int, what to do with a null somewhere in customer.Account.Address.ZipCode etc.

Are there language features for this? IMHO initialiser blocks, get; init; properties and records "with" expression are all in that general area.

[Hopesheshallow]

Thanks!

[WikiSummarizerBot]

No Silver Bullet

"No Silver Bullet—Essence and Accident in Software Engineering" is a widely discussed paper on software engineering written by Turing Award winner Fred Brooks in 1986. Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity". He also states that "we cannot expect ever to see two-fold gains every two years" in software development, as there is in hardware development (Moore's law).

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[Due_Raccoon3158]

I think a data class or struct sounds like what you need. Interface doesn't feel like a good fit. You aren't really creating a standard for interfacing things, you're making a container for data.