3 ms·

I don't understand that page in the slightest, but a lot of if-cascades can be factored more cleanly using polymorphism. http://c2.com/cgi/wiki/wiki?Polymorphi

by sunir 12y ago

I don't understand that page in the slightest, but a lot of if-cascades can be factored more cleanly using polymorphism. http://c2.com/cgi/wiki/wiki?PolymorphismVsSelectionIdiom http://c2.com/cgi/wiki/wiki?PolymorphismVsSelectionIdiom (Disclaimer. I wrote the top of that wiki page in a former life.)

userbinator 12y ago
However, if you already have a class type for each key I think that's precisely what I was trying to say - polymorphism makes sense when you already have a bunch of classes to do it with, and classes which already contain lots of other fields and methods; it doesn't make sense to create a bunch of classes just to use polymorphism.
- nardi 12y ago
  Often, though, a series of complicated if statements is hinting at a type system for your objects that hasn't yet materialized in your code. I find it's a good idea to always look at cascading if statements and switch statements and ask, "Would this be cleaner if I reified these concepts as types?" http://en.wikipedia.org/wiki/Reification_(computer_science) http://en.wikipedia.org/wiki/Reification_(computer_science)
  - alttab 12y ago
    This is the single most important trick for factoring out shitty code. I cannot believe how many times reification collapsed complexity in our code base, or how not using it was the source of bugs. If you have cascading ifs, there is a good chance there is a huge set of ifs for every place this type system is missing. Meaning, if you wanted to add another "case" to a feature, you are modifying cascading ifs in 5-10 places, not even just one. Wrapping up all of this code into an implementation of an interface, that is "hooked in" at each contact point allows you to add a cohesive new use case by generating a new implementation of an interface, instead of "forgetting 2 places in the code" and causing massive bugs or issues because of it. It of course, also makes it easier to test!
    - platz 12y ago
      So to reify a type involves making an abstraction, which is odd because reify seems the inverse of making an abstraction...
      - derefr 12y ago
        The abstraction already existed in your mental model. You're reifying it by making it something the code can refer to/reflect on/pass around.
        Arkadir 12y ago
        The only difficulty is naming the abstraction :)

by sunir 12y ago

userbinator 12y ago

However, if you already have a class type for each key I think that's precisely what I was trying to say - polymorphism makes sense when you already have a bunch of classes to do it with, and classes which already contain lots of other fields and methods; it doesn't make sense to create a bunch of classes just to use polymorphism.

nardi 12y ago
Often, though, a series of complicated if statements is hinting at a type system for your objects that hasn't yet materialized in your code. I find it's a good idea to always look at cascading if statements and switch statements and ask, "Would this be cleaner if I reified these concepts as types?" http://en.wikipedia.org/wiki/Reification_(computer_science) http://en.wikipedia.org/wiki/Reification_(computer_science)
- alttab 12y ago
  This is the single most important trick for factoring out shitty code. I cannot believe how many times reification collapsed complexity in our code base, or how not using it was the source of bugs. If you have cascading ifs, there is a good chance there is a huge set of ifs for every place this type system is missing. Meaning, if you wanted to add another "case" to a feature, you are modifying cascading ifs in 5-10 places, not even just one. Wrapping up all of this code into an implementation of an interface, that is "hooked in" at each contact point allows you to add a cohesive new use case by generating a new implementation of an interface, instead of "forgetting 2 places in the code" and causing massive bugs or issues because of it. It of course, also makes it easier to test!
  - platz 12y ago
    So to reify a type involves making an abstraction, which is odd because reify seems the inverse of making an abstraction...
    - derefr 12y ago
      The abstraction already existed in your mental model. You're reifying it by making it something the code can refer to/reflect on/pass around.
      - Arkadir 12y ago
        The only difficulty is naming the abstraction :)