Timeline for Patterns for passing context through a method chain
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 4, 2015 at 9:18 | comment | added | winkbrace | +1 for saying you have one correct way instead of the correct way | |
| Dec 3, 2015 at 21:09 | comment | added | CLF | If we are talking alternative paradigms, isn't this one area monads can be used? The compuational context can be precisely captured by eg a Reader or State monad, so we can reason about the dependency as well. | |
| Nov 30, 2015 at 14:03 | comment | added | Scant Roger | ... Claiming that functional patterns are preferred to OO patterns is highly controversial ;) When I say "fighting the tool", I mean losing the richness or what's possible because of an over-zealous viewpoint. I don't know your background, but if Haskell/F#/whatever got you excited about pure functional programming, maybe try SmallTalk to get you excited about pure OO programming. To be clear, I'm not claiming that OO is better than functional. Not at all. I'm just highlighting that each paradigm tackles the OP's problem in different, yet effective, ways. | |
| Nov 30, 2015 at 13:51 | comment | added | Scant Roger | @DavidArno The functional features in modern OO languages are a separate paradigm -- a perfectly legitimate paradigm, but still a separate paradigm. That's why all three approaches above may be possible within a single language. What you seem to be arguing is that pure OO is now defunct given functional features. I don't believe that's correct. Both paradigms have their strengths and weaknesses. Sounds like you've been bitten by the functional bug and that's great. Just don't let it cloud your judgement about what's possible with other tools. | |
| Nov 30, 2015 at 9:19 | comment | added | David Arno | @ScantRoger, I agree another paradigm can be adopted, namely the functional paradigm. Interestingly, most modern "OO" languages have a growing list of functional features and so it's possible to stick with those languages and adopt the function paradigm, without "fighting the tool". | |
| Nov 30, 2015 at 9:17 | comment | added | David Arno | @KevinKrumwiede, to an extent, you have applied reducto ad absudium to my comment, but your point is still well made. Invariance on state is an important part of "moving on from OO" . So avoiding mixing functionality and state has to allow enough functionality in a state object as needed to achieve invariance (encapsulated fields set by the constructor and accessed via getters). | |
| Nov 28, 2015 at 4:29 | comment | added | Kevin Krumwiede | @DavidArno A class that is all state and no functionality has no mechanism for enforcing invariant relationships in the state. Such a class is not at all OO. | |
| Nov 27, 2015 at 22:57 | history | edited | Scant Roger | CC BY-SA 3.0 |
grammar
|
| Nov 27, 2015 at 22:21 | comment | added | Scant Roger | @DavidArno I'd suggest using a different paradigm vs. concluding object statefulness is "one of the biggest mistakes make by the OO paradigm" and then circumventing the paradigm. I have nothing against almost any approach but generally dislike code where the author is fighting their tool. Private state is a distinguishing feature of OO. If you eschew that feature, you lose some of OO's power. | |
| Nov 27, 2015 at 17:21 | comment | added | David Arno | Claiming that passing parameters around within OO methods is a code smell is a highly controversial statement. I'd argue the complete opposite: encouraging mixing state and functionality within a class is one of the biggest mistakes made by the OO paradigm and avoiding it by injecting dependencies directly into methods, rather than via a constructor is a sign of a well designed piece of code, whether OO or not. | |
| Nov 27, 2015 at 15:51 | history | answered | Scant Roger | CC BY-SA 3.0 |