Open-Closed principle: is irrelevant if you own the code-base and you don't have any other external clients using the code. If someone knows when this might not be true, please let me know.
De4sher might beg to differ here; I'd venture to guess you don't approach a problem solution in an undisciplined manner. maybe in prototype form, but not approaching production quality. at least, I do not.
It applies to any reusable code, if the behaviour of any bit of code needs to be specialised then it needs to follow the principle. Clients of your software aren't just outside people, they could be colleagues or even you in 2 months time.
soggy code. nice. antithesis of DRY being: WET, or We Enjoy Typing, which I can tell you is not the case, if don't need to. I'd rather show the results of the tests.
Liskov substitution... I understand what he's doing, but how would replacing every instance of an class with one of the more specialized classes lead to the same behavior? This doesn't make any sense. And making the "Report" class not be abstract doesn't solve any problem either. Replacing any instance of a type with an instance of any of its subtypes changes behavior period. Seems like liskov simply says "Create abstract classes". While in my opinion, creating interfaces is better, even that doesn't have anything to do with the original definition.
De4sher in practice, I find you really cannot isolate one principle from the others. for instance, I believe you take Dependency Injection with Liskov Substitution; you might inject an instance of an INTERFACE (NOT ABSTRACT), where that's concerned. for sake of example, it's probably overkill to get into much in the way of containers, which there are many.
+De4sher LSP doesn't forbid overriding behavior if it doesn't violate assumptions about the base behavior. His example isn't great because report.Print() probably *should* be interchangeable between letters and tabloids. But imagine an OnlineReport class where Print() throws InvalidOperationException. Now any method that calls report.Print() will break if you give it an OnlineReport. Or if a method is expected never to return negative numbers (maybe you sqrt the result), the overridden method also should not return negative numbers, etc.
Open-Closed principle: is irrelevant if you own the code-base and you don't have any other external clients using the code. If someone knows when this might not be true, please let me know.
De4sher might beg to differ here; I'd venture to guess you don't approach a problem solution in an undisciplined manner. maybe in prototype form, but not approaching production quality. at least, I do not.
It applies to any reusable code, if the behaviour of any bit of code needs to be specialised then it needs to follow the principle.
Clients of your software aren't just outside people, they could be colleagues or even you in 2 months time.
soggy code. nice. antithesis of DRY being: WET, or We Enjoy Typing, which I can tell you is not the case, if don't need to. I'd rather show the results of the tests.
Michael Powell moist code
Liskov substitution... I understand what he's doing, but how would replacing every instance of an class with one of the more specialized classes lead to the same behavior? This doesn't make any sense. And making the "Report" class not be abstract doesn't solve any problem either. Replacing any instance of a type with an instance of any of its subtypes changes behavior period. Seems like liskov simply says "Create abstract classes". While in my opinion, creating interfaces is better, even that doesn't have anything to do with the original definition.
De4sher in practice, I find you really cannot isolate one principle from the others. for instance, I believe you take Dependency Injection with Liskov Substitution; you might inject an instance of an INTERFACE (NOT ABSTRACT), where that's concerned. for sake of example, it's probably overkill to get into much in the way of containers, which there are many.
+De4sher LSP doesn't forbid overriding behavior if it doesn't violate assumptions about the base behavior. His example isn't great because report.Print() probably *should* be interchangeable between letters and tabloids. But imagine an OnlineReport class where Print() throws InvalidOperationException. Now any method that calls report.Print() will break if you give it an OnlineReport. Or if a method is expected never to return negative numbers (maybe you sqrt the result), the overridden method also should not return negative numbers, etc.