Timeline for Help with inheritance hierarchy design
Current License: CC BY-SA 3.0
18 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 16, 2014 at 8:01 | vote | accept | jayars | ||
Jan 8, 2014 at 13:21 | comment | added | jayars | Yup, you can just assume so. The 2 examples I've added in the update is to show how it's unfeasible to use inheritance (single parent) for my scenarios. It's starting to seem like I really need to use a strategy pattern here. That way, 1) my Base class will not need those empty NotImplemented methods, 2) I can share common code in a strategy, and 3) I can enforce abstract methods/interface within the strategy class. I'm just a bit hesitant, because I'll have to do this for every method in Base that behaves this way. | |
Jan 8, 2014 at 13:03 | comment | added | itsbruce | But they are returning the same basic class of object? Would hope so, but it's not clear from the diagram, which shows the way the data is retrieved rather than what it actually is. | |
Jan 8, 2014 at 12:13 | comment | added | jayars | GetData is an example of different implementation across subclasses. Eg, one need to parse xml to recreate the data object, while another uses the Binary formatter, and a third simply holds and restores from memory. | |
Jan 8, 2014 at 11:53 | comment | added | itsbruce | It looks to me as if the different getData() implementations return different types... | |
Jan 8, 2014 at 11:46 | comment | added | jayars | GetData corresponds to Run, GetSelectionName and GetXmlList to proc. Next example, RunQuery(Run), InsertData(proc). | |
Jan 8, 2014 at 10:59 | comment | added | itsbruce |
In the update, what corresponds to proc() in the new diagram? getData() ?
|
|
Jan 8, 2014 at 10:02 | history | edited | jayars | CC BY-SA 3.0 |
added 116 characters in body
|
Jan 8, 2014 at 9:51 | history | edited | jayars | CC BY-SA 3.0 |
New figure example
|
Jan 8, 2014 at 8:40 | answer | added | itsbruce | timeline score: 2 | |
Jan 8, 2014 at 7:02 | answer | added | Euphoric | timeline score: 3 | |
Jan 8, 2014 at 6:47 | comment | added | Euphoric | "each one of those would have to be a strategy, which seems like overkill/overengineering." I disagree. I think it is perfectly fine to express this behavior in it's own class. | |
Jan 8, 2014 at 6:39 | history | edited | gnat | CC BY-SA 3.0 |
personal stuff removed
|
Jan 8, 2014 at 5:25 | history | tweeted | twitter.com/#!/StackProgrammer/status/420788299490656256 | ||
Jan 8, 2014 at 5:06 | comment | added | Nick Bray | This sounds like the perfect example for a strategy pattern. You could also have type 2 and type 3 inherit from a type 5 that inherits from Base. This would be the standard inheritance way, but I would stick with strategy. If you later add classes that share run then they can reuse different run methods. Especially if you already have an example of two types sharing a run method. | |
Jan 8, 2014 at 4:34 | comment | added | Robert Harvey | Have you considered creating a default implementation in the top-level class, letting your descendant classes call Proc in the Top-level class, and only overriding Proc if necessary? | |
Jan 8, 2014 at 4:05 | review | First posts | |||
Jan 8, 2014 at 6:39 | |||||
Jan 8, 2014 at 3:47 | history | asked | jayars | CC BY-SA 3.0 |