Slashdot Mirror


Pragmatic Programmers on Designing with Metadata

Bill Venners writes "This week I've published the fourth installment of my interview with Andy Hunt and Dave Thomas, the authors of the best-selling book, The Pragmatic Programmer. In this installment, Dave and Andy talk about their recommended approach to design in which details are pulled out of the code and stored as metadata. This installment of the interview really made me think. Their focus on metadata sounded non-intuitive when I read their book, but in actually talking to them about it, I got the feeling they might be on to something. Check out: Abstraction and Detail."

1 of 26 comments (clear)

  1. Rules, not metadata by Twylite · · Score: 2, Informative

    Maybe I've got the wrong idea from the interview, but what was discussed was rules, not metadata.

    Business rules are a well known aspect of enterprise software development, especially in light of the many old(er) custom-build systems in which the rules were hard-coded. A business rule is "sales tax is 7%", or "customer pays a 1.5% surcharge is payment is more than 2 days late".

    Metadata is a partner and also an opposite to a business rule. Metadata is quite simply "data about data". The fact that the value "7%" is "sales tax" is metadata; but the fact that the current value of the sales tax is 7% is not. The age-old concept of a "data dictionary" is an embodiment of what metadata is.

    A rules engine is (rather simply) a powerful extension of the practice of declaring constants for significant literals (which are or could be subject to change); quite often one which allows runtime modification of the value rather than requiring a recompile. Rules engines also tend to provide mechanisms for evaluating compliance with the rule, or performing calculations based on rules.

    --
    i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net