>>106209742
>do you have an example?
consider this object-oriented fizzbuzz where everything is separated into interfaces:
List<String> values = new FizzBuzz()
.setDefaultOutput(new InputNumber())
.addRule(new DivisibleBy(3), new Text("Fizz"))
.addRule(new DivisibleBy(5), new Text("Buzz"))
.fizzBuzz(1, 100);
if I were to add a new rule where for each number that is prime appended the cardinal number (ie. spelled out, not digits), I would only need to implement a new Condition, a new Output and add a rule when fizzBuzz is executed (don't need to modify or even read fizzBuzz itself):
List<String> values = new FizzBuzz()
.setDefaultOutput(new InputNumber())
.addRule(new DivisibleBy(3), new Text("Fizz"))
.addRule(new DivisibleBy(5), new Text("Buzz"))
.addRule(new IsPrime(), new CardinalNumber())
.fizzBuzz(1, 100);
if I were to change how the DivisibleBy condition works, or how some Output implementation works, I only need to modify that one small class and still not touch or read the FizzBuzz class or other classes
if I were to add some fundamental change how FizzBuzz worked (eg. add an option for a rule to override/ignore previous rules), I would only need to modify addRule() and fizzBuzz() methods of the FizzBuzz class without having to touch any of the Conditions or Outputs
before you try to make a point about premature abstraction: consider each of the interfaces were extracted only after it was needed to extend the functionality. you only see it already extracted because of length limits on posts
>all i ever see is premature abstraction (e.g. creating a common interface for two operations because surely all future requirements will fit into this model, yikes they didn't, cut corner or refactor? jam it into the interface it is)
can you in turn give an example of a scenario of that happening? your example doesn't make much sense to me
