3 ms·
OOP should be thought of as a way to structure your code, not as a way to model the problem domain. When used properly, it can give pretty good results, yet int
by adwn 11y ago
OOP should be thought of as a way to structure your code, not as a way to model the problem domain. When used properly, it can give pretty good results, yet introductions to OO usually start with objects/classes representing real-world entities.
- TuringTest 11y ago> not as a way to model the problem domain ...unless your problem domain is a simulation of objects in a physical environment, in which case OO is well suited "as is". But certainly, that's typically not your everyday scenario in development.
- adwn 11y agoAre you refering to simulations of physical phenomena? If so, then I disagree: You'll fare much better with large arrays of dumb structs, which enable immense performance improvements on today's computing architectures.
- TuringTest 11y agoIf you need to incorporate flexibility in the environment, with agents displaying lots of different behaviors (such as with video games), the large arrays of dumb structs will be much harder to organize. I agree that those structures are easier to make efficient, but for handling the hierarchy of different types of objects with different but related behaviors, you'll basically have to reimplement a limited form of object-orientation and message passing.
- halayli 11y agoOOP is an abstraction tool. When you have a problem you need to divide it into sub problems and represent each sub problem as an abstraction. The end result is that the collection of abstractions should model the problem domain.
- adwn 11y ago> The end result is that the collection of abstractions should model the problem domain. Sure, but that doesn't imply that individual objects/classes should model individual abstractions 1-to-1, as would be the case for the typical Vehicle, Car, Boat example classes.
- halayli 11y agoI didn't say individual objects/classes. I specifically said "collection of abstractions".