It'll probably comes as no surprise that I am very skeptical of the benefits of trying to over generalise in this way. I'll try to make my case for why.

By analogy. It could be postulated that the steering wheels on cars; the handlebars on a (motor)bikes; the control columns on commercial aircraft; the joysticks on military jets; the tillers on small boats; even the rains on horses and horse-drawn carriages; all serve the same purpose and could be replaced with a single control.

It is probably technically feasible to attach servos to the bit in a horses mouth and have the rider use a joystick to steer, but it is probably overkill.

Conversely, I'm not sure I'd want to fly in a 777 if the pilot used a pair of leather straps or big tiller to steer it.

Whilst that analogy is jokey, don't take it for a joke. Perhaps the single hardest element of modern software design to get right is the abstraction. And by far the biggest mistake in recent years is over abstraction. It is far too easy to get carried away with finding abstract similarities between things that have no business being conflated.

By example. A few years ago, I worked on the periphery of an MIS system for a large retail chain. This system was heavily OO layered over an RDBMS. Within it, everybody--personnel, suppliers, customers et al.--were instances of a Person class. Which mapped to one large primary table in the DB with lots of specialisations (FKs) hanging off of it. The problems came when trying to control access to it. Which came to a head when a minor programming error lead to sensitive information about customers being sent out to a supplier.

Putting all your data in one place may sound like a great idea from the data warehousing/analysis perspective, but security-aware organisations use compartmentalisation for very good reasons. It may lead to apparent redundancies, but it also leads to "redundant" layers of security, which you'll be very glad of when one of the layers is breached.

Do not let theoretical principles override pragmatism and practicality without serious consideration on a case by case basis.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

In reply to Re: polymorphic data-driven rendering? by BrowserUk
in thread polymorphic data-driven rendering? by metaperl

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.