3 ms·
As soon as I saw "public class PriceSpecification" I got a creepy feeling. Why shouldn't the specifications be more purely data, like {field:"price", operator
by xsmasher 7y ago
As soon as I saw "public class PriceSpecification" I got a creepy feeling.
Why shouldn't the specifications be more purely data, like
{field:"price", operator:">", level: 150 }
Then you DON'T need to write new classes for DividendYieldSpecification and PeRatioSpecification - you just need to make sure those fields are available in the data, or write support to derive them when they are requested.
- wpietri 7y agoThings would work both ways, of course. For me the difference is a) the extent to which I want to make the domain model explicit, and b) how much I value build-time elimination of bugs vs run-time flexibility. Data-driven approaches leave a lot implicit, meaning that it can be hard to answer the question, "What's really possible here?" And they can only be verified to the extent you have all the data, which usually means a lot of checks are deferred to run time.