Timeline for Is it okay to have objects that cast themselves, even if it pollutes the API of their subclasses?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 1, 2015 at 14:33 | comment | added | Pete Kirkham | @QuestionC yes, I read the assertion that can't be solved polymorphically to exclude the visitor option operating on the list of Bases themselves | |
| Apr 30, 2015 at 22:01 | comment | added | QuestionC | Also this is mostly identical to the visitor pattern solution. The difference is you're implementing the Visitor::OnSub1()/Visitor::OnSub2() methods as Sub1::act()/Sub2::act() | |
| Apr 30, 2015 at 21:58 | comment | added | QuestionC | This is IMO the right answer. Understand that the Context doesn't need to be a new class, or even an interface. Usually the context is just the caller, so calls are in the form action.act(this). If getFrequency() and getRandomIngredients() are static methods, you might not even need a context. This is how I would implement say, a job queue, which your problem sounds an awful lot like. | |
| Apr 29, 2015 at 23:44 | comment | added | codebreaker | You're right, and I don't think I can salvage this question. I ended up picking a bad example, so I'll probably just post another one. The getFrequency() and getIngredients() were just placeholders. I probably should have just put "..." as the arguments to make it more apparent that I wouldn't know what they are. | |
| Apr 29, 2015 at 22:35 | history | edited | Pete Kirkham | CC BY-SA 3.0 | attempt to clarify what's odd about example |
| Apr 29, 2015 at 22:18 | comment | added | Pete Kirkham | @codebreaker you really need to clarify your question then - in most systems there would be a valid reason for calling a bunch of functions agnostic of what they do; for example to process rules on an event or perform a step in a simulation. Usually such systems have a context in which the actions occur. If the 'getRandomIngredients' and 'getFrequency' are not related, then then shouldn't be in the same object, and you need yet a different approach, such as having the actions capture the source of ingredients or frequency. | |
| Apr 29, 2015 at 20:38 | comment | added | codebreaker | You get that my sort of absurd methods are designed to show the differences in what the classes can do once their subclass is known (and that they have nothing to do with each other), but I think having a Context object just makes matters worse. I might as well just be passing in Objects to the methods, casting them, and hoping they're the right type. | |
| Apr 29, 2015 at 20:30 | history | answered | Pete Kirkham | CC BY-SA 3.0 |