5 ms·
In reality we are never designing classes for a bookstore, shapes, or animals. Often times the problem is new and the classes go through an iterative lifecycle
by halayli 11y ago
In reality we are never designing classes for a bookstore, shapes, or animals. Often times the problem is new and the classes go through an iterative lifecycle of design/refactor.
Book authors should spend more time thinking about examples. I see this in almost every oo book.
- martijn_himself 11y ago> In reality we are never designing classes for a bookstore, shapes, or a animals. This 100x. Anyone who has tried to solve real world problems finds out a very small amount of code written fits the model where a class corresponds to a family of physical objects, and probably much less even fits the model of polymorphism. 95% of classes end up just being fairly random containers for data and behaviour and OO just does not offer anything of value.
- Kiro 11y ago> 95% of classes end up just being fairly random containers for data and behaviour and OO just does not offer anything of value. Thank you. I always feel I'm doing something wrong since my OO code always ends up like this.
- JustSomeNobody 11y agoThat's OK. As long as you're constantly refactoring. If you step back and look at how you're manipulating your data and you're like, "Ok, data comes in and I first turn it right, then I turn it left, then I flip it over... Ah! I might be able to use Pipes and Filters here!" You can then refactor your classes to be more organized.
- adwn 11y agoOOP 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.
- 11y ago
- samth 11y agoDid you look at the linked book? The first two examples are of a coffee product and a GPS location. Of course real-world code often is bigger than textbook examples, but this complaint is hardly applicable here.