Object Model, Correct or Most Intuitive Way

Question

I am trying to figure out the best way to set up this model. I pretty much did it one way, but I am considering doing it another way. This is a learning experience so wasted time does not matter.

namespace FirstWay { public class CrateOfBags { public string crateId { get; set; } public string originCountry { get; set; } public List<BagOfApples> bagList { get; set; } } public class BagOfApples { public double weight { get; set; } public string bagId { get; set; } public List<apple> appleList { get; set; } } public class apple { public string appleId { get; set; } public string color { get; set; } public Boolean rotten { get; set; } } }

//Or This

 namespace SecondWay { public class CrateOfBags { public string crateId { get; set; } public string originCountry { get; set; } } public class BagOfApples : CrateOfBags { public string bagId { get; set; } public double weight { get; set; } } public class apple : BagOfApples { public string appleId {get;set;} public string color { get; set; } }

}

Possible Questions

Apple Questions : How many Rotten apples were Delivered? Which Bags and/or which crates did rotten apples come from? First way: could loop through each crate, then bag,then apple and count. Second way: could loop just through apples and add parent properties to HashSet (one way to keep out duplicates)

Crate Questions. Find number of Crates From Each Country ? First way: Loop through just crates and keep a counting list, array, whatever. Second way: Would have to loop through all apples and only care about crates.

One Problem I ran into is I know very little about an apple as its own entity. I only know which crate it is from by starting the foreach loops from crate

But if I want to ask a question like "how many green apples are in a particular batch (by id)?" I am also having issues depending on the way.

It seems awkward to me to say that an apple is a child of a bag, like a dog is child of animal. However I like the idea of being able to freely move an manipulate apples, such as switch which bags they are in simply by changing the parent property bagid. I am not looking for solutions to the particular questions so much as just if one of these is better (more flexible, efficient, intuitive) then another, or if I am missing something completely such as using another technique. Thanks a lot.

P.S. This is not the real model, but a pretty decent representation.

usr · Accepted Answer · 2013-02-20 22:56:42Z

The 2nd approach seems clearly wrong from a data modeling perspective: an apple is not a BagOfApples. Inheritance is supposed to create substitutability: Can you always put an apple where a BagOfApples is expected? I don't think so. This is the Liskov substitution principle (and it is violated).

In database terms the 2nd model is denormalized. It can be created from the first model by joining all 3 tables together thereby creating redundant data. That's an anti-pattern because when you change something you have to change it in more than one place (if you forget that it is a silent data corruption).

Ok thank you. Does the first way seem ok, or is there some other better way? I am not happy with this route because an apple itself should know something about its origin (such as country or batch).For instance if I wanted to put apples in a large storage container for drying, I should be able to measure "drying rate" and then still find country of origin.
You would solve that by giving the apple a reference to a BagOfApples. Your 3 classes are a tree with three levels and what you want is the parents linking to the children using lists and the children linking to the parent using object references. That makes the tree navigatable in either direction. You have to be careful to keep the links in sync, though.

D Stanley · Accepted Answer · 2013-02-20 23:00:42Z

It seems awkward to me to say that an apple is a child of a bag

God, because that's wrong. An apple is not a bag, and thus should not inherit from it.

Your first model looks fine. The only suggestion I'd consider is genericizing Bag so it could be re-used:

public class CrateOfBags<T> { public string crateId { get; set; } public string originCountry { get; set; } public List<Bag<T> bagList { get; set; } } public class Bag<T> { public double weight { get; set; } public string bagId { get; set; } public List<T> ItemList { get; set; } } public class apple { public string appleId { get; set; } public string color { get; set; } public Boolean rotten { get; set; } }

I know very little about an apple as its own entity. I only know which crate it is from by starting the foreach loops from crate.

This is solved by using back-references, meaning an apple has a reference to it's bag, which has a reference to it's create. THis does not always make sense, however, especially if there are multiple container types that could contain an Apple or if an Apple should not know about it's bag.

Collectives™ on Stack Overflow

Object Model, Correct or Most Intuitive Way

2 Answers 2

2 Comments

Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

2 Comments

Comments

Related