11–17 of 17 posts
The most confusing things about OOP is inheritance vs subtyping vs union. You have a dequeue class, the stack and queue inherit dequeue. But dequeue is a subtype of stack and queue. About union, could i say an abstract class is a union (implicitly) of all its subclasses ?
I have quite often wanted the ability to easily collect the arguments to a function call together in a structure with the function itself, and defer the execution of the method. I want a closure essentially but with the ability to reflect and inspect the arguments and function, potentially make changes, and execute it later.
Of course the only real way to do this in most languages is to make every single thing i want to do a single-function class with public "argument" members. But that messes with the structure of the code.
It would be really nice to have some syntactic sugar for extracting a class for function calls and their arguments.
The decree pattern seems similar the solution I've described above but avoided implementing because it sounds crazy.
This seems similar to an itch I've had for a while on many languages. I have quite often wanted the ability to easily collect the arguments to a function call together in a structure with the function itself, and defer the execution of the method. I want a closure essentially but with the ability to reflect and inspect the arguments and function, potentially make changes, and execute it later. Of course the only real…
https://stackoverflow.com/questions/3188048/how-to-bind-argu...
I thought this was a sarcastic description of an antipattern to start with. Whenever I see classes with verbs in their name I see it as a bad smell. In the ProcessPayment example he says the pattern is good because it lets you split the construction of the payment from its execution. Soooo why not have a Payment class with a process method? Am I missing something?
It dawn on me that the latter is precisely what people at Java do, and I've reached the conclusion that this way of writing software is enforced by Java developers who realized they needed to learn Ruby because their job prospects are better, and are simply retrofitting what they used to do in a new programming language.
I thought this was a sarcastic description of an antipattern to start with. Whenever I see classes with verbs in their name I see it as a bad smell. In the ProcessPayment example he says the pattern is good because it lets you split the construction of the payment from its execution. Soooo why not have a Payment class with a process method? Am I missing something?
I've been asking myself *this* for the year-ish I've been working with Ruby on Rails. The idea of encapsulating any piece of logic into a class function in order to call a single method is very weird, given that you can do the very same thing with just a method on a model class. Payment.process seems superior in many areas (understanding, readability, explainability) compared to PaymentProcessor.new(payment: payment)…
Extracting important business behaviour into objects allows applying OO (ie, powerful despatch rules) where it is valuable.
Subtyping your model to achieve many of these possible usecases would give poor design results.
For example, if payment processing were in Payment.process() the Payment entity would need to be subtyped or composed for any of 1) a different payment gateway, 2) a sales tax in a new jurisdiction, 3) a new confirmation, or 4 a new payment flow. Having all that in your model entity is probably wrong.
Simple behaviour is fine in the model, major business TN usually not.
Earlier quoted context omitted.
I've been asking myself *this* for the year-ish I've been working with Ruby on Rails. The idea of encapsulating any piece of logic into a class function in order to call a single method is very weird, given that you can do the very same thing with just a method on a model class. Payment.process seems superior in many areas (understanding, readability, explainability) compared to PaymentProcessor.new(payment: payment)…
Behaviour is what needs to despatched, and behaviour is what benefits from applying eg. strategy pattern, delegation, orchestration. Extracting important business behaviour into objects allows applying OO (ie, powerful despatch rules) where it is valuable. Subtyping your model to achieve many of these possible usecases would give poor design results. For example, if payment processing were in Payment.process() the Pa…
There's nothing at all wrong with having, say, a PaymentGateway and SalesTax classes and composing them with Payment in whatever way makes sense given their interdependent relationships. Code that has real life analogs to objects tends to be much cleaner, in fact.