3 ms·

The issue wasn't divergence. The issue was that there was no requirement that TextBlocks should behave like rectangles. It's very possible that DRY could appl

The issue wasn't divergence. The issue was that there was no requirement that TextBlocks should behave like rectangles. It's very possible that DRY could apply even where divergence is expected. Suppose we had a requirement that "A user should not be able to resize a TextBlock if they are not allowed to read the text." At the outset, the read & resize permission logic might be identical & DRY is easy to apply. Nobody would be surprised if eventually resizing permissions became more restrictive. Even at that point, DRY applies. If you repeated the shared logic, and later you add new restrictions to the read permissions, it'd be easy to introduce a bug where you forget to restrict resizing permissions accordingly.

dragonwriter 7y ago
> The issue wasn't divergence. The issue was that there was no requirement that TextBlocks should behave like rectangles. But they had the same current requirements. So, ideally, the implementation of the common behavior should have been shared but shared in a way which didn't tightly couple the two consumers with each other, so that it would be simple for either to stop using the shared code.
mattkrause 7y ago
> The issue was that there was no requirement that TextBlocks should behave like rectangles. Sure, though that’s not quite what the new code did. Instead, it added a new abstraction (createBox), and then used that to incidentally assign the same behavior to TextBlocks and Rectangles. Your change could easily be accomplished by changing the last line to check the permissions and call createBox or something else, depending. I’d guess that createBox would also be useful for many other shapes, but if you wanted to do something totally different, like a star with handles at each point, you could just....not call createBox, and write a totally independent “let star()” function that does its own thing; it doesn’t seem like a base class constructor is forcing you to call createBox or anything. So....this code doesn’t actually seem that bad to me. What am I missing?

dragonwriter 7y ago

> The issue wasn't divergence. The issue was that there was no requirement that TextBlocks should behave like rectangles. But they had the same current requirements. So, ideally, the implementation of the common behavior should have been shared but shared in a way which didn't tightly couple the two consumers with each other, so that it would be simple for either to stop using the shared code.

mattkrause 7y ago

> The issue was that there was no requirement that TextBlocks should behave like rectangles. Sure, though that’s not quite what the new code did. Instead, it added a new abstraction (createBox), and then used that to incidentally assign the same behavior to TextBlocks and Rectangles. Your change could easily be accomplished by changing the last line to check the permissions and call createBox or something else, depending. I’d guess that createBox would also be useful for many other shapes, but if you wanted to do something totally different, like a star with handles at each point, you could just....not call createBox, and write a totally independent “let star()” function that does its own thing; it doesn’t seem like a base class constructor is forcing you to call createBox or anything. So....this code doesn’t actually seem that bad to me. What am I missing?