From: MikkelFJ Date: 2003-05-14T07:17:33+09:00 Subject: Re: [OO design] Objects VS Datastructures "Simon Vandemoortele" wrote in message news:Zcdwa.1038$1u5.25@afrodite.telenet-ops.be... > The problem I see in this setup is that my 'Objects' are very passive; > they are not much more than datastructures with an attitude. Their whole > interface consists of setters and getters. I've been wondering if this > is still OO ? Shouldn't I be sending 'messages' instead of "taking some > 'Object', pulling out some information to shove it somewhere else" ? That is a good observation. Many OO designs fail partially because designers say - wow this is an thing in the problem domain. It has name so it must be an object. Thus we create a class for that object and figure out how to relate it to other objects. When designing properly, it is often discovered that non-obvious entities are the real objects in the problem domain. For example the address book could have an object called ContactUpdateManager. This manager would server a single client and coordinate its efforts with other ContactUpdateManager objects, or possibly with other UpdateManagers that updates non-contact information. Note: this is just an example. I'm not sure it would actually be smart to create UpdateManagers - it's just a different perspective. To the question about datastructures: In a functional programming language such as OCaml, you would typically have datastructures instead of objects. Instead you have a family of functions that operate on these datastructures. If you want to map this view onto objects again, you get a kind of manager style object that manages the datastructure, not a single data entity. I guess this is why functional programming is relatively successfull (not popular, just successful). When I first learned Ruby, I wrote a pet text adventure program. Ruby was very good at this. But I didn't create a single object of a class I had designed. I used lots of arrays and hashes. It would have been death by objects to do the same with a class for every thing I made. When I eventually made it socket enabled so I could connect via telnet, I realized I needed to have multiple instances. Thus I wrapped all the code in one large Adventure class and made an instance for each connection. Had I created multiple players in the same game, I would problably have had Player objects and Game objects. But the zillions of commands, verbs, rooms, relations between rooms etc. was much better handled by datastructures. So I say be conservative with object creation. Use it when it helps, but don't make everything an object. Note: Ruby's Everything is an object, has to do with consistency of the type system it doesn't mean you should go out and create a new class for every piece of data. It's interesting to follow you observertations throughout the project. You are touching the essential problems of good software design instead of just mindlessly coding along. Mikkel