Skip to main content
Software Engineering

Return to Answer

Minor fix to improve how meaning is imparted around a couple of small details.
Source Link
Vector Zita
Vector Zita
  • 2.5k
  • 11
  • 21

The way you imagine it right now, all your objects have specific types and you can use dynamic type inference or type checking to perform things in the calc engine. This is not too bad, it willwould serve you betterwell to separate your objects in strong types and use some type checking in the calc engine than to play with field names to see if an object is of a given type, etc.

The way I would suggest, though, is to reconsider what it is that this calc engine does. If it calculates the price, for example, based on the properties, and your objects are wildly different in terms of characteristics (and, of course, have multiple, quite disparate, properties), you can simply put some "blood" into the object classes (try to search forlook into anemic domain models and how they don't help much in the end) and give them functionality. Let them calculate the price on their own, so they implement a common interface, say IFinancial, which has a method GetPrice(). This way, the calculation takes place INSIDE the object and you do not need to type-check anything where the use-case code is organized. You just ask the objects.

The way you imagine it right now, all your objects have specific types and you can use dynamic type inference or type checking to perform things in the calc engine. This is not too bad, it will serve you better to separate your objects in strong types and use some type checking in the calc engine than to play with field names to see if an object is of a given type, etc.

The way I would suggest, though, is to reconsider what it is that this calc engine does. If it calculates the price, for example, based on the properties, and your objects are wildly different in terms of characteristics (and, of course, have multiple, quite disparate, properties), you can simply put some "blood" into the object classes (try to search for anemic domain models) and give them functionality. Let them calculate the price on their own, so they implement a common interface, say IFinancial, which has a method GetPrice(). This way, the calculation takes place INSIDE the object and you do not need to type-check anything where the use-case code is organized. You just ask the objects.

The way you imagine it right now, all your objects have specific types and you can use dynamic type inference or type checking to perform things in the calc engine. This is not too bad, it would serve you well to separate your objects in strong types and use some type checking in the calc engine than to play with field names to see if an object is of a given type, etc.

The way I would suggest, though, is to reconsider what it is that this calc engine does. If it calculates the price, for example, based on the properties, and your objects are wildly different in terms of characteristics (and, of course, have multiple, quite disparate, properties), you can simply put some "blood" into the object classes (try to look into anemic domain models and how they don't help much in the end) and give them functionality. Let them calculate the price on their own, so they implement a common interface, say IFinancial, which has a method GetPrice(). This way, the calculation takes place INSIDE the object and you do not need to type-check anything where the use-case code is organized. You just ask the objects.

Included a small code excerpt to highlight the key points of the answer.
Source Link
Vector Zita
Vector Zita
  • 2.5k
  • 11
  • 21

Because developers like to see code:

public class FinancialObject : IFinancial
{
   //Common properties of IFinancial

   Currency GetPrice(); //Currency is some proper abstraction.

   //Maps property code-string (key) to property value.
   Dictionary<string, string> AdditionalProperties { get; }

   //Maps property code-string (key) to property user-friendly description/name.
   Dictionary<string, string> AdditionalPropertyDescriptiveNames { get; }
}

Because developers like to see code:

public class FinancialObject : IFinancial
{
   //Common properties of IFinancial

   Currency GetPrice(); //Currency is some proper abstraction.

   //Maps property code-string (key) to property value.
   Dictionary<string, string> AdditionalProperties { get; }

   //Maps property code-string (key) to property user-friendly description/name.
   Dictionary<string, string> AdditionalPropertyDescriptiveNames { get; }
}
Source Link
Vector Zita
Vector Zita
  • 2.5k
  • 11
  • 21

It generally depends on the requirements but, more often than not, it depends on how much time you have at your disposal, because when lots of conflicting requirements arise, you may have to actually begin implementing and build from there, improving your architecture as you go (which may include throwing code away).

First of all, remember, multiple databases with lots of tables and loads of records per table is nothing special for most good database implementations and good ones already have your back "covered" in that respect anyway, so this is not something you should worry about in advance.

Then, you should (usually) not design your architecture and reason about it on the basis of the implementation. You should design and reason on the basis of the abstraction. You are talking about (and consequently thinking of) classes and fields rather than the actual objects of your domain. I see you mention very specific numbers such as "20 data elements" and "30 data elements", but have you got them "down" yet, those specific 20-30 data elements (as an example)? Note down 20-30 data elements (less will also do) and check what they have in common for your use case. Financial products probably have a price, maybe a few other properties in common.

Remember, however, that while the representation of a domain may be almost completely detached from potential use cases, it's the use cases that have to be implemented. On many occasions, it can assist to conceptualize the relationships and clarify (to yourself) the true reasons why you are looking at it in that specific way. Then you can fine-tune your own reasoning by oscillating back-and-forth between domain logic and use case.

For example, financial products are, in a sense, interesting in terms of their "financial" properties, which should be common (e.g. price), then a name/description and, potentially, one or more depictions/images, so that one can manage a group of objects, facilitate purchasing and various other activities, all of which share the common ground of simply representing simple or complex operations on a database.

But take a look at your described use case. Rows and columns, lots of them, acting as a virtualization of the content of a database. Then, objects appear to have lots of properties. I will make the unpopular statement that, whatever your "calc engine", odds are extremely low that all these properties are relevant for that engine. If, for some reason, they are and you need them all, and they are also not common ground, then you should start refactoring your calc engine in the following simple way:

The way you imagine it right now, all your objects have specific types and you can use dynamic type inference or type checking to perform things in the calc engine. This is not too bad, it will serve you better to separate your objects in strong types and use some type checking in the calc engine than to play with field names to see if an object is of a given type, etc.

The way I would suggest, though, is to reconsider what it is that this calc engine does. If it calculates the price, for example, based on the properties, and your objects are wildly different in terms of characteristics (and, of course, have multiple, quite disparate, properties), you can simply put some "blood" into the object classes (try to search for anemic domain models) and give them functionality. Let them calculate the price on their own, so they implement a common interface, say IFinancial, which has a method GetPrice(). This way, the calculation takes place INSIDE the object and you do not need to type-check anything where the use-case code is organized. You just ask the objects.

Oh, and about these rows and columns that have to be filled with the rest of the (non-common?) properties, well, if there is nothing "financial" about them, then I do not see why you need these properties in your calc engine. If they are there just for reference, you can model them as key-value pairs. A Dictionary<string, string> will be all you need.

Few-sizes-fit-all solutions arise when either trying to model an incomplete domain, or trying to incompletely model a domain. They are better avoided of course, although I am no expert on that, plus the real world is too complicated to deal in absolutes!