5 ms·

Polymorphism and inheritance often assume that differences are hierarchical. The real world is often NOT hierarchical, or at least may easily change to not be h

by tabtab 8y ago

Polymorphism and inheritance often assume that differences are hierarchical. The real world is often NOT hierarchical, or at least may easily change to not be hierarchical in the future. Noun "classification" of most domain things is messy. It's one of the reasons for the backlash in the 2000's against OOP as a domain modelling system. IF's often handle unpredictable variations better. Features are often better viewed as a buffet restaurant instead of an animal kingdom classification tree as found in biology. The biology classification-like approach popular in the 90's usually fails outside of biology. And, "lots of little methods" can make code rather hard to read & follow in my opinion. Your eyes may differ.

jstimpfle 8y ago
Are you sure meant to reply to me? I agree with you. But note that even better than a fixed number of if/elses or switches, is physically separating the data for the different cases from the start (where possible). This way if statements _can_ be avoided. That was my point. It's the approach taken by the relational model, used in RDMBSes.
- tabtab 8y ago
  The devil's in the details and each situation is different. One has to know the domain well to make decent guesses about likely future change patterns. Making code future-friendly is hard and requires experience both in coding and the domain. Let's look at UI's. Should "buttons" and "hyperlinks" be considered different "types" of things? Or should we blur the distinction to be flexible? In this view, a button is a style applied to a hyperlink rather than a distinct "kind" of thing. Once you pre-type them into distinct things, it's hard to merge them: the code base hard-wires a clear distinction and too many things rely on a type-centric arrangement. A more flexible approach is to take the view that things, perhaps ANY thing, wants the ability to "act like" a hyperlink and/or button. Linking is then viewed as an optional feature, not part of some base "type". Same with drop-downs versus combo-boxes versus text boxes: we can model these via feature smorgasbords instead of sub-types and probably get a more flexible framework in the process that may also be reusable in other widgets. But the flip-side is that such flexibility can confuse newbies. Hard-wired hierarchies are quicker to learn, and test.
dragonwriter 8y ago
> The real world is often NOT hierarchical, or at least may easily change to not be hierarchical in the future. The real world is an undifferentiated unified whole, but you can't actually work with it without dividing it up and labelling/modelling it, and most useful models have a heirarchical structure. OTOH, they usually aren't a single-inheritance heirarchies, and most OOP languages either handle multiple inheritance poorly or not at all.
- your-nanny 8y ago
  OOP is lousy as an ontologicsal model of the stuff making up the real world. But that doesn't make it not useful for building designed systems.
  - tabtab 8y ago
    True, but that doesn't imply one should turn most IF statements into polymorphism, or other OOP constructs. OOP is one of multiple tools in our toolbox.

by tabtab 8y ago

jstimpfle 8y ago

Are you sure meant to reply to me? I agree with you. But note that even better than a fixed number of if/elses or switches, is physically separating the data for the different cases from the start (where possible). This way if statements _can_ be avoided. That was my point. It's the approach taken by the relational model, used in RDMBSes.

tabtab 8y ago
The devil's in the details and each situation is different. One has to know the domain well to make decent guesses about likely future change patterns. Making code future-friendly is hard and requires experience both in coding and the domain. Let's look at UI's. Should "buttons" and "hyperlinks" be considered different "types" of things? Or should we blur the distinction to be flexible? In this view, a button is a style applied to a hyperlink rather than a distinct "kind" of thing. Once you pre-type them into distinct things, it's hard to merge them: the code base hard-wires a clear distinction and too many things rely on a type-centric arrangement. A more flexible approach is to take the view that things, perhaps ANY thing, wants the ability to "act like" a hyperlink and/or button. Linking is then viewed as an optional feature, not part of some base "type". Same with drop-downs versus combo-boxes versus text boxes: we can model these via feature smorgasbords instead of sub-types and probably get a more flexible framework in the process that may also be reusable in other widgets. But the flip-side is that such flexibility can confuse newbies. Hard-wired hierarchies are quicker to learn, and test.

dragonwriter 8y ago

> The real world is often NOT hierarchical, or at least may easily change to not be hierarchical in the future. The real world is an undifferentiated unified whole, but you can't actually work with it without dividing it up and labelling/modelling it, and most useful models have a heirarchical structure. OTOH, they usually aren't a single-inheritance heirarchies, and most OOP languages either handle multiple inheritance poorly or not at all.

your-nanny 8y ago
OOP is lousy as an ontologicsal model of the stuff making up the real world. But that doesn't make it not useful for building designed systems.
- tabtab 8y ago
  True, but that doesn't imply one should turn most IF statements into polymorphism, or other OOP constructs. OOP is one of multiple tools in our toolbox.