Timeline for Exceptions and the Liskov Substitution Principle
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 3 at 13:26 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 408 characters in body
|
| Aug 3 at 13:18 | comment | added | Doc Brown | @Flater: I found some time to rewrite my answer, maybe this is more in line with your ideas now. | |
| Aug 3 at 13:16 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 686 characters in body
|
| Jul 28 at 23:37 | comment | added | Flater |
Just to point out that I'm not tone deaf to the existence of exceptions: I see no issue with documenting the existence of the exception for any consumer of said piece of logic (who sees it as a black box), but there is a difference between adding something to the documentation and including it as part of the IService interface purely by merit of an implementor having implemented it of their own accord.
|
|
| Jul 28 at 23:23 | comment | added | Flater | "I have doubts this counts as an OCP violation." What if tomorrow there's a new implementation of this interface, which throws a new kind of exception? You have to go back and explicitly include this in the interface contract, and update everyone who makes used of that interface to now account for this new exception (= implementor's implementation detail) possibly being thrown. That whole "I need to go back and update this list of options" is precisely what OCP tries to combat, an extension should not require that another things needs to be modified to account for said extension. | |
| Jul 28 at 23:22 | comment | added | Flater | "Think of IService and its implementation as compiled code in a black box library and the decorator as code outside this component." You could say that about any codebase in an effort to sidestep any argument about the internal design of said codebase. The alleged OCP violation is an internal one, I agree on that; but I'm not agreeing that we should consider it a violation only if it leaks beyond whatever arbitrary boundary we choose to judge it against. | |
| Jul 28 at 16:27 | comment | added | Doc Brown | @Flater: thats correct, but the OCP is not an end in itself, and from the way the question was asked, I guess the asker does not see the OCP here as a primary design goal. Moreover, it is somewhat debatable if this is really an OCP violation. Think of IService and its implementation as compiled code in a black box library and the decorator as code outside this component. The component then can be reused without source code changes or recompilation even with this new exception from a decorator. I have doubts this counts as an OCP violation. | |
| Jul 28 at 8:55 | comment | added | Flater | Forcing the interface to contain the combined aggregate of all of its implementors' exceptions is a variation on an OCP violation. We're discussing a grand total of two here, so it's not the end of the world, but regardless of size I do consider this a violation. | |
| Jul 28 at 5:15 | history | answered | Doc Brown | CC BY-SA 4.0 |