5 ms·

> is a set of rules that absolutely are not at odds with one another Yes, if you take them as general guidelines, not dogmatic rules with variable interpretati

• mpweiher 5y ago
  Hmm...polymorphism is almost invariably simpler than if/else or switch/case, so not seeing the contradiction.
  • fortylove 5y ago
    Is that view not subjective though? Might someone think that if/else is simpler?
    • qayxc 5y ago
      Depends entirely on the metric used. Cyclomatic complexity would put if/else behind polymorphism while using lines of code and depth of inheritance would favour the if/else way. That's the crux with software - there's not always an objectively better solution in terms readability/comprehensibility and some metrics that try to capture these qualities are inherently at odds with each other.
  • ajuc 5y ago
    I've seen this happening a lot: - you have the same if-then-else in 3 places in code with 3 different effects - you refactor it to polimorphism (Enum with a few overloaded methods works well in java) - now one of these places need additional condition so you make it a little more complex - year passes - you have eldritch abomination of OOP instead of 3 if-then-elses with slightly different conditions because at no point someone was brave enough to refactor back into if-then-elses as the special cases piled up
    • ziml77 5y ago
      Exactly my experience with polymorphism. It starts out looking super clean but then the business requirements shift and each has its own edge cases that turn it into a giant mess, often ending up as a mix of both polymorphism and convoluted if statements.
      • deleted 5y ago
        [deleted]
• juped 5y ago
  They aren't. This is why pattern matching and typeclasses (to use the Haskell words, though I know other words are in use as well) have become increasingly popular features in languages.
• beebmam 5y ago
  Yeah, polymorphism is in no way simple in lots of languages/frameworks. It's actually quite complex in many common languages/frameworks. This is absolutely contradictory in my opinion, but I welcome disagreement :)
  • mcv 5y ago
    And then there's a language like Scala where switch/case is so naturally integrated that it actually becomes the cleaner solution and you basically have to use it. Whatever approach is clean or not can vary wildly by language. Or framework. I do like clean code, but I think the article has a point: it's a very vague concept.
• onion2k 5y ago
  Polymorphism is more complex than a switch/case in a single instance. Across a large codebase using polymorphism instead of hundreds of different switch/cases is simpler, especially when you need to change something. Encapsulating what a class should do within the class instead of in an external code block is much simpler when you're working on something big.
  • _0w8t 5y ago
    Polymorphism is a switch, but it is the switch over object kind, not action. In fact if there are only few subclasses compilers for some languages where a global analysis is possible implement polymorphic calls as switches over the object tag. And notice how if one needs to add a new action, all objects are required to implement it. In typical OOP languages that touches many files even if the action is used only once. So polymorphism works nicely if there are only few actions but many different objects, like in a typical GUI. But in cases of few objects and many actions, for example, doing a lot of different queries over few data sets it leads to a lot of boilerplate. Switch over actions will lead to less code.
• rk06 5y ago
  Polymorphism can replace multiple if/else/switch/case with a single one. It has benefits, if you do not apply it dogmatically everywhere
• hyperman1 5y ago
  I see polymorphism vs if/... more as a tradeoff. For example: Suppose the program has to make a choice. When the choice exists only in 1 place, use an if/switch. When the choice exists in multiple places, polymorphism centralizes it and quickly becomes the simple option. For example, a change in law required us to make a choice based on a date: If (thing.someBusinessDate < 2010-06-01) { doTheOldWay();} else{doTheNewWay();} after a while, a few edge cases sprang up, and we got variants of this code hiding in multiple corners. Then the law changed again with a new cutoff date. So we adapted to polymorphism: interface TheWay{ edgecase1(); edgecase2();...} class TheOldWay implements TheWay{...} class TheNewWay implements TheWay{...} class TheNewNewWay implements TheWay{...} TheWay wayDetector(thing){/* all the ifs here */} Unfortunately, adding just one more 'if' was always the cheapest choice. The refactoring was nevertheless clearly a better choice: it enabled us to point out more forgotten edge cases, avoiding costly mistakes.
  • viceroyalbean 5y ago
    I agree with you, especially in instances where that decision logic is unrelated to the data that is actually being used. In your example you'd have to pass "thing" everywhere just for that if-statement, but it might not be used for anything else. That said, I think "simple" if/else or switches are much more common than the complex cases that fit polymorphism, so it seems a bit off to have it as a general rule to prefer polymorphism.