3 ms·

Why is color of a car an issue with OOP? Without knowing your the use cases, neither of us will model it correctly for the job at hand. A car obviously has mu

Why is color of a car an issue with OOP? Without knowing your the use cases, neither of us will model it correctly for the job at hand. A car obviously has multiple colors. It has at least two: exterior and interior. Quite often there are two-tone colors. But as a manufacturer, I'm going to guess that each interior and exterior color scheme has an ID. If you are a car manufacturer, the interior and exterior color scheme ID would be all you need.

TheOtherHobbes 8y ago
car -> list of parts -> part.color Although in fact you should probably allow for composite parts with multiple sub-colors, where each part supports its own enumerated list of possible colors. In spite of appearances, it's not a completely trivial problem. Maybe OP meant that to someone doing naive modelling, defining a car class and then giving it a single color property is going to cause problems. Which of course it is. And maybe also that OOP encourages this kind of superficial thinking. Initial ignorance - and initial assumptions - about the problem domain get baked into the architecture. It becomes increasingly hard to change them as time passes and code grows around them. Essentially, OOP mixes up data schema and software architecture in a brittle way. Of course you can build abstract classes for variable schemas, but then you're really doing meta-OOP, and there are probably better options. OOP isn't the only paradigm that does this, but the brittleness seems to be characteristic. If you keep your schemas separate and explicit it's not usually all that difficult to extend/change them. If they're buried in class definitions and you don't have a dependency map to see which part of the schema is used in which part of the code, non-trivial refactoring can become a complete nightmare.

3 ms·

Why is color of a car an issue with OOP? Without knowing your the use cases, neither of us will model it correctly for the job at hand. A car obviously has mu

by wedowhatwedo 8y ago

TheOtherHobbes 8y ago
car -> list of parts -> part.color Although in fact you should probably allow for composite parts with multiple sub-colors, where each part supports its own enumerated list of possible colors. In spite of appearances, it's not a completely trivial problem. Maybe OP meant that to someone doing naive modelling, defining a car class and then giving it a single color property is going to cause problems. Which of course it is. And maybe also that OOP encourages this kind of superficial thinking. Initial ignorance - and initial assumptions - about the problem domain get baked into the architecture. It becomes increasingly hard to change them as time passes and code grows around them. Essentially, OOP mixes up data schema and software architecture in a brittle way. Of course you can build abstract classes for variable schemas, but then you're really doing meta-OOP, and there are probably better options. OOP isn't the only paradigm that does this, but the brittleness seems to be characteristic. If you keep your schemas separate and explicit it's not usually all that difficult to extend/change them. If they're buried in class definitions and you don't have a dependency map to see which part of the schema is used in which part of the code, non-trivial refactoring can become a complete nightmare.