Am I too granular?!

[jfrost10]

Ok, so here's the situation:

I have a Vehicle class. This vehicle has a few properties like chassis, drive type, etc.

Here's how I'd like to model the classes:

Vehicle class
- Chassis Class (ID, Description)
- Drive Type Class (ID, Description)

Basically, I want to use composition of objects: a Vehicle object has a Chassis and Drive Type object within it. Here's how my co-workers would like to see it:

Vehicle class
- ChassisID (integer)
- DriveTypeID (integer)

So just holding the identifiers as integers within the vehicle class.

I was taught in school that you should always favour composition, and that objects that are associated with other entities should reference those entities objects, not their ID.

What are your thoughts? Am I being too granular with this?!

Thanks,

D'Arcy

 

[dragonwell]

I generally agree with the composition approach, too. The only drawback that I can see is in filling a collection of objects. Do you have to load all of the object's properties just to display a list? If you are lazy-loading the properties that are not primitive types, or somehow create a proxy version that just contains a simplified version of the full object, I suppose that would be fine.

David

 

[jfrost10]

Hey Dave,

When the user selects a vehicle to modify, or add, the system loads a vehicle object in memory. As the user enters data and selects items from a drop list, the changes are reflected in the vehicle object.

So the way I'd like to handle a possible situation is like this:

The user selects an item from a drop list of Chassis types. This list is filled with Chassis objects, not just key/value list objects.

Once the user has selected it, the code ASSIGNS the Vehicle's Chassis object to be the selected object.
So instead of saying

Vehicle.ChassisID = ddlChassis.SelectedValue

I just say

Vehicle.Chassis = ddlChassis.SelectedItem

You still need the line of code, but with composition I can access the chassis description without going back to the database or having to hold another property in the vehicle.

So its not for list displaying purposes (I'd just use a dataset for that), its for actual object manipulation.

The objects are so small as it is (id, description) that I can't see how they'd have a huge performance hit.

But I'm not really sure.

Thanks,

D'Arcy

 

[DotNetDoc]

If all your class hold is

Chassis Class (ID, Description)
- Drive Type Class (ID, Description)

Why dont you just use an enum inside of the vehicle class.

Enum Chassis

ExtendedChassis = 0
FlatChassis = 1


End Enum

Enum DriveType

FourWheelDrive
RearWheelDrive

End Enum

Then in you class you properties could hold the enum

Public Property VehicleDriveType As Drivetype


etc...





DotNetDoc
M.C.S.D.
---------------------------------------

Tell me and I forget. Show me and I remember. Involve me and I understand.
- Anonymous Chinese Proverb

-----------------------------------

If you can't explain it simply, you don't understand it well enough.
- A. Einstein

 

[jfrost10]

Because lets say that the users want to add a new Chassis type.

If all they do is access an object which will add one for them, and all chassis lists are populated with chassis objects from the db, then there is no maintenance that needs to be done on the development side.

However, once you start using enums, as soon as one item is added to the db, then you have to go into code and change the enum. Then you have to create an update package and send it out to all the clients. Unless its just one client asking for it, which means that you now have a custom version of the software for one client. And if 3 other clients ask for new chassis types, but they're all different, now you either have 4 custom versions of the code, with different enum lists, or you blanket everyone with the same list, which they may either not want some of the items, or the items are the same and just named something slightly different.

That has to be the biggest run-on sentence ever.


D'Arcy

 

[DotNetDoc]

My answer was based on the original question not what I would do personally.

If the data is coming from a database then what would be the benifits of taking it from the DB and loading it into an object? Since all the Object would be holding would be ID and Description for a vehicle property.

I hope that wasn't a run-on.




DotNetDoc
M.C.S.D.
---------------------------------------

Tell me and I forget. Show me and I remember. Involve me and I understand.
- Anonymous Chinese Proverb

-----------------------------------

If you can't explain it simply, you don't understand it well enough.
- A. Einstein

 

[jfrost10]

Heh, sorry Doc. Forgot to post earlier that we came to the decision at work to go with the object route instead of the enums.

You mentioned that your response was to my initial question, not what you would do. But what would you do? How would you handle it?



D

 

[Tracyd]

Hey jfrost10,

I keep going back and forth about the same question. Not using Enums but whether to store the type as an object or just have two separate properties in the class, one for the id and another for the description. Maybe the description property is read-only.

Can you tell me why you decided to store objects? Sounds like you just want to get to the description easily. Would two properties work just as well?

I'm trying to justify the extra work to create all these small classes to represent types (we have a ton of them).

Thanks for any insight.

 

[jfrost10]

Hey Tracy,

This sort of discussion really becomes a religious decicion based on methodology, experience, etc., but I'll give you a bit of insight as to why we went the object route.

One of the things that I kept in mind when designing the objects was the "loosely coupled, highly cohesive" rule in OO development. The idea that objects shouldn't be tightly tied together, and yet should still be easily used together.

In my case, our Vehicle class had a bunch of sub-classes that could either have been properties of the class, or objects. Some of these objects were just types (like the chassis), and some held data entered by the user.

The decision to represent user-defined data as objects was an easy one, since there would be updates to handle, deletions, additions, etc. to the database.

But for types...it really comes down to how your architecture is. Within our application, all drop lists, grids, etc. are bound to objects within collections; we rarely bind a grid to a datatable (usually, its data that won't be edited if we make the exception). The reason is that instead of fiddling with identifiers and descriptions, as well as other fields that may be present and required to be stored, we just use the object, which is cleaner than worrying about individual fields.

Because of how we bind data to our controls, it made sense to make all the types objects, and even more when the type properties of our objects became objects (which is also a key point in OO development...although some would argue this).

By putting the types in their own objects, it was also easier to reuse code for interfaces where the users could edit certain type lists themselves, which wouldn't have been the case if we just made them properties of the main object (duplicating work).

I hope this helps, let me know if you have any other questions.

D'Arcy

 

[wgcs]

I agree with DotNetDoc's statement:
If the data is coming from a database then what would be the benifits of taking it from the DB and loading it into an object? Since all the Object would be holding would be ID and Description for a vehicle property.

While in this specific instance, you may not end up with the problem I'm thinking of, there's definitiely the potential:

Say that a Car has a Chassis type, and a Body Style.
A chassis type has a composition material and a manfacturing location

a Composition material has a material type and a thickness.

a manufacturing location has an address (street, city, state, zip), a supervisor (a name, phone number, office number), a list of employees (each with a name, phone, etc), and on, and on.

a Body Style has a Style Description, and a Paint Type.

a Paint Type has a color, glossiness index, metallic fleck count, etc.


So, when you load the Car object, if the Chassis object automatically loads, then all the object inside a Chassis also load, including the manufacturing location, potentially including objects for every employee in the company!

You have to stem the tide at some point...
Why not at the top-level-object?

The method I've settled on is this:
If a data entity has a specific need to be manipulated, along with it compositing entities, I'll build a composite object for that purpose, with a limited depth-of-scope.

However, I'll also build a parallel "flat" object that only represents the top level of that data entity, which is used in other contexts where the compositing entities don't make sense (such as getting a list of cars).

Ideally, the composite object would be a descendent of the flat object.

 

[jfrost10]

So, when you load the Car object, if the Chassis object automatically loads, then all the object inside a Chassis also load, including the manufacturing location, potentially including objects for every employee in the company!

You're missing one very important concept in OO:
Highly cohesive, loosely coupled.

Although a chassis type may have a manufacturing location, that doesn't mean that the manufacturing location is part of the chassis type object. In fact, a manufacturing object would more than likely have a collection of chassis objects representing which ones it creates.

In a database view, you'd have a chassis table, a manufacturing table, and an association table between the two.

In a class diagram, you'd have a chassis object and a manufacturing object...but nether would necessarily contain the other. I may have a screen that shows vehicle information, which includes a chassis; but I wouldn't need a manufacturing object. Then, maybe I have a site that shows details about a particular chassis. In that scenario, I would require a manufacturing object...but it wouldn't have to be part of the chassis.

Composition is great, but keeping to the highly cohesive/loosely coupled rule is better by far.

Thanks for the post,

D'Arcy