The Old Joel on Software Forum: Part 4 (of 5) - "attribute" driven class design

"attribute" driven class design

For better or worse, when I'm involved in developing a class library I'll notice "most" of my behavior will be modeled via fields/properties as opposed to methods. For example, I tend to lean towards designing my Customer object to operate like:

Employee.TendedTransactions.Add(transaction);

As opposed to:

Employee.TendTransaction(transaction);

In other words; in my experience I'll tend to create class libraries with, mostly, properties and the classes responsibility and behavior represented in the properties and relationships between the classes as opposed to having methods? My "Use Cases" are represented as collections of objects as opposed to methods w/ a strict input/output?

What's your take on this? Is this bad?

Steve
Tuesday, April 27, 2004

Homework assignment?

name withheld out of cowardice
Tuesday, April 27, 2004

I haven't though about it enough to say outright that it is bad, but I've been nodding my head in agreement with those people who have been saying lately that clases should be modeled with an interface that is more "What are you doing" rather than "How do I fiddle with the implementation to get this done". I feel like your method would have to change its interface if you had to substantially change the implementation of your transaction behavior.

Keith Wright
Tuesday, April 27, 2004

"the classes responsibility and behavior represented in the properties and relationships between the classes as opposed to having methods"

Whether this is good or bad, depends rather on whether it does the job, and will continue to do the job under likely future conditions.

What it isn't, is object-oriented programming. If that worries you, then change your style. If not, then... not. Personally I prefer objects to have methods that suggest how they are supposed to be used. And that hide information, not just encapsulate data. But it's horses for courses...

Dave Hallett
Tuesday, April 27, 2004

(Disclaimer: I don't know the exact meaning of "tend" in this context. I'm assuming it means something similar to "process").

A couple of things spring to mind:

1. You're exposing too much information for the operation. If a user of your class wants to process a transaction, he shouldn't need to know that you have a transaction collection, nor should he need to look up the collection's interface.

2. The operation is not as intuitive.

Employee.TendTransaction(transaction)

clearly means "take this transaction, and process it"

Employee.TendedTransactions.Add(transaction)

is more dubious - it means "take this transaction, and put it in the collection of processed transactions". Does this operation also process the transaction? Or is the processing done by another method? If so, which one? These are questions a user of your class would pose himself upon examining you class interface.

Paulo Caetano
Wednesday, April 28, 2004

Paulo,

You're right . . . exposing behavior via various properties as I'm doing I abstract to a level of misunderstanding.

I need to break myself of this habit . . . I think I obtained the habit because of my work with SQL-DMO which operates in this manner.

Nothing wrong w/ exposing strongly typed collections . . . but, for behavior, I must concentrate on adding appropriate methods.

Thanks for helping realize the obvious.

Steve
Wednesday, April 28, 2004

"Nothing wrong w/ exposing strongly typed collections"

I agree. I also do it often. I don't know how "correctly OO" it is, but I've found it too useful to care.

When I said "too much information", I was referring only to the TendTransaction() operation.

"Thanks for helping realize the obvious."

You're welcome :)

Paulo Caetano
Wednesday, April 28, 2004

>>Employee.TendedTransactions.Add(transaction);
>>
>>As opposed to:
>>
>>Employee.TendTransaction(transaction);

I think they can both be appropriate depending on the situation. The first seems to apply when you're treating Employee as a record/data/struct object. The second would be for when TendTransaction has some behavior that doesn't need to be seen by callers.

Matt
Wednesday, April 28, 2004