Object Orientation Question

[Anon]

Hey all,

As I start to really get a grip on OO, I am enjoying all the benefits that OO brings (it's taken a while.. old habits die hard... can you say COBOL?). There is really only one big question left...

Shouldn't everything be an object?

To clarify: I know there are advantages to using global variables and just passing a single variable from place to place in ones' code, but shouldn't data be in object for too?

It struck me that, while there is extra overhead in creating data objects isn't there the advantage of a consistent interface to the data?

For example if I pass a complex multi dim array around my code and something in the array changes, then I have to change lots of code in lots of places. However, if I pass the array around in an object, and the object knows how to access the array, then the most I will have to do is modify the objects array access code. If I made the object interface well, I may not have to change a thing.

Thoughts? Observations? Good web references that might clarify this for me would be most appreciated.

Steve Warwick

wherever you go, &this.

[Anon]

You shouldn't be passing arrays into objects. That should never happen. If the array means some tangible thing, it should be in an object itself with reasonable methods to act on that array.

With that said, the larger picture and the answer to your question is that there is no such thing as 'data objects'. Objects have data AND behaviour. If it just has data, it really isn't an object but a data structure.

The answer to your other question, 97% of the system can be in objects, but you'll have 3% glue code in html files.

You will also need some global variables like $dbConnection signifying your connecting to the database, as that is probably used on every page.

If you got other questions, ask away. I'm very good with objects and can help you out.

[Anon]

also with that array comment, you never want to pass in any array into another object because that basically means another object is responsible for 'modifying' data that doesn't belong to it. In the OO paradigm, that is wrong even though you can do it - it's really a flaw in php and in most programming language including Java. You should design objects so that each object has it's own data and can behave on that data. If it's modifying data that doesn't belong to it, that method is probably not in the right class to begin with.

[Anon]

Thanks for the response... very helpful!

Another question if you have a moment. Is it OK to use an object inside an object? Or is that an indication that the new object should be an extesion of the first object?

Example:
DBobj - abstraction class

class OtherObj {
var dbConnector = new DBobj;
}

Thanks,

Steve Warwick

wherever you go, &this.

[Anon]

Indirection is not a bad thing at all Steve. In fact, you'll most likely use indirection a lot to 'reuse' services'. There are 3 types of object containment (object's containing objects)

1. The object should physically contain the object. A Car contains and Engine so the Car object would have an instance of an Engine class. This makes the constructure of Car responsibile for constructing the engine.

2. The object contains a physical object, but it may not have it too. Like a Car has a CD Player object. The constructor is not responsible for constructing the CD Player but you need a method called ->addCdPlayer( ... );

3. The object does not physically contain the contained object at all, but it to either reuse code or to delegate to an object that is responsible for carrying out that action.

a) In the first case, a MSWord and MSExcel objects would contain code to print files. But you'll notice that the print manager is the same for both of these applications. So you would make a class called PrintManager and MSWord and MSExcel would use 'contain' the PrintManager and simply have the same methods as it but will delegate them to the contained Print Manager. This is just to reuse code, nothing more. There is no physical containment.

b) Sometimes you have a class that is modifying members of another class (It's okay to read members). That shouldn't happen, even if you do have accessor methods (get & set). So you will use delegation (indirection) to move the method out of the first class and into the other class, but to ensure the code in your software still works, you keep the method defined in the original class. Like this:

function a() {
$b->a();
}

The original class really doesn't contain the logic for a(), but it still provide the same behaviour. It just makes someone else responsible. This is very similar to the PrintManager example but it's for a different reason.

Hope that helps.

[egervari]

Indirection is not a bad thing at all Steve. In fact, you'll most likely use indirection a lot to 'reuse' services'. There are 3 types of object containment (object's containing objects)

1. The object should physically contain the object. A Car contains and Engine so the Car object would have an instance of an Engine class. This makes the constructure of Car responsibile for constructing the engine.

2. The object contains a physical object, but it may not have it too. Like a Car has a CD Player object. The constructor is not responsible for constructing the CD Player but you need a method called ->addCdPlayer( ... );

3. The object does not physically contain the contained object at all, but it to either reuse code or to delegate to an object that is responsible for carrying out that action.

a) In the first case, a MSWord and MSExcel objects would contain code to print files. But you'll notice that the print manager is the same for both of these applications. So you would make a class called PrintManager and MSWord and MSExcel would use 'contain' the PrintManager and simply have the same methods as it but will delegate them to the contained Print Manager. This is just to reuse code, nothing more. There is no physical containment.

b) Sometimes you have a class that is modifying members of another class (It's okay to read members). That shouldn't happen, even if you do have accessor methods (get & set). So you will use delegation (indirection) to move the method out of the first class and into the other class, but to ensure the code in your software still works, you keep the method defined in the original class. Like this:

function a() {
$b->a();
}

The original class really doesn't contain the logic for a(), but it still provide the same behaviour. It just makes someone else responsible. This is very similar to the PrintManager example but it's for a different reason.

Hope that helps.