Timeline for Decorator or Facade
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot |
Commonmark migration
|
|
| Nov 27, 2018 at 23:27 | comment | added | Kain0_0 | @R.Schmitz Be patterns tools or not to you; the failure was relying on a single methodology to phrase and answer the question. By perspective I meant orthogonal perspectives. To know you have orthogonality the minimum is three. Sufficiency may require more. Design patterns are high-level generic plans this is a single perspective, a single way to phrase and answer the question. Domain Driven Design; Test Driven Design; or thinking in a different model of computing say Logic, Functional, or State Machines; Literally any other way of phrasing the question gives perspective, and enables choice. | |
| Nov 27, 2018 at 11:15 | comment | added | R. Schmitz | @Kain0_0 I have to strongly disagree with "Design Patterns are a tool" and everything else that results from that thinking. Design patterns are just names for often-used solutions. Having only one perspective wasn't the issue here at all, design patterns gave OP 2 perspectives. From 2 different patterns, which both weren't really right for the problem, because OP "thought backwards": "I have a solution, which problem can I solve with it". There's a lot of unnamed solutions out there that one can only arrive at by thinking about the problem (but might also arrive at a pattern this way). | |
| Nov 23, 2018 at 0:07 | comment | added | Kain0_0 | @R.Schmitz Design Patterns force you to think backwards. This is a good thing. Having one perspective on a problem is bad. With different perspectives, you can spot what is worse because there are better alternatives. With one perspective how do you know it is good? Design Patterns are a tool, same as Test Driven Design, Domain Driven Design, Encapsulation, Message Passing, and bit manipulation. As with any tool, incorrect use results in injury to yourself, others, or the code. I do agree Design Patterns are incorrectly used here - they just aren't the problem - It is having one perspective. | |
| Nov 22, 2018 at 11:15 | comment | added | Creepin | @R.Schmitz, yes I actually did it that way, which is not the best approach which I noticed now. | |
| Nov 22, 2018 at 10:31 | comment | added | R. Schmitz | @Kain0_0 I agree, that's why I wrote "That's about all the advantage you get". They are helpful when the code is already written, to explain it to somebody. But for writing the code, they do more bad then good, because it reverses the thinking process: You see a good solution for a certain problem and then you start thinking "Hey, I also have this problem" - but you forgot about the "fine print", your problem is only 90% the same and the solution doesn't actually fit well anymore. Which I think is what happened here. | |
| Nov 22, 2018 at 10:22 | comment | added | Creepin | Thanks for your answer, I think you nailed the problem and I can totally follow your arguments, so I will take your approach with the given naming proposals | |
| Nov 22, 2018 at 10:20 | vote | accept | Creepin | ||
| Nov 22, 2018 at 7:43 | comment | added | Neil | "Let's start off nice: I hate your second solution." Boss? Is that you? | |
| Nov 22, 2018 at 2:11 | comment | added | Kain0_0 | I disagree with patterns only being good to tell people "I solved it with {pattern name}". They are useful for understanding why certain compositions of software occur so frequently in just such a way. It provides insights into the strengths and weaknesses of code, the problems being addressed, and sometimes even who and why it was addressed that way. They can facilitate communication of otherwise paragraph long explanations. That being said, I completely agree with the rest of your answer. Patterns are not magic pixie dust. Before you implement one: study it first, again, and then some more | |
| Nov 21, 2018 at 18:53 | history | answered | R. Schmitz | CC BY-SA 4.0 |