Timeline for How to model my Child Classes without violating OO Principles
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 30, 2018 at 13:46 | vote | accept | Chris | ||
| May 30, 2018 at 13:23 | comment | added | Greg Burghardt | @Chris: At this point you are coupling your data access logic to the entity. They should be separated, due to the question you just asked in your comment. | |
| May 30, 2018 at 12:44 | comment | added | Chris | This looks great! One small question though, how would I handle the self.childOneSpecificMember if in each child class (in the original) it has different extended members? So for instance if Parent represents a Vehicle, maybe a Child represents a Truck and I need to set the contents of the bed. I could turn Parent in to a Role like you are doing above and have each child implement it, but how would I reuse the code for common attributes like wheels? | |
| May 30, 2018 at 6:47 | comment | added | amon | I would also tend towards this design. (1) In Python, It wouldn't even be necessary to create the API client classes, as free functions can be passed around. However, this code is a stand-in for Java, where we'd have to use classes and define an ApiClient interface instead (basically, a Strategy Pattern). (2) It is unclear how those child specific members should be treated. If they are not accessed outside of the API clients, then things get difficult. | |
| May 29, 2018 at 13:50 | history | answered | Greg Burghardt | CC BY-SA 4.0 |