Hello!

If I want to create an application for a multimedia store that can handle
selling/leasing music albums and film how can the inheritance look like.

I have just thought something like this.
The class that is most general is an abstract class called Product.
Below this Product class I have two more abstract classes called Music and
Film.
Below this Music I have a concreate class called CD and below
the Film class I have also a concrete CD class.

Does this sounds reasonable ?

//Tony

On 26-04-2011 04:26, Tony Johansson wrote:
> If I want to create an application for a multimedia store that can handle
> selling/leasing music albums and film how can the inheritance look like.
>
> I have just thought something like this.
> The class that is most general is an abstract class called Product.
> Below this Product class I have two more abstract classes called Music and
> Film.
> Below this Music I have a concreate class called CD and below
> the Film class I have also a concrete CD class.
>
> Does this sounds reasonable ?

(I assume that the class below Film is DVD not CD)

Yes - the design makes some sense.

It is a completely standard 1985-1995 design.

:-)

It can still be a valid design today.

But I will recommend that you look at the functionality of
those classes. Do they all have functionality that really
belongs there?

Or would a design with:
- IProduct interface
- Music and Film classes implementing IProduct
- Music class has a property MediaType that can contain enum value
MusicMediaType.CD
- Film class has a property MediaType that can contain enum value
FilmMediaType.DVD
be better?

Arne

"Arne Vajhøj" <(E-Mail Removed)> skrev i meddelandet
news:4db7569d$0$309$(E-Mail Removed)...
> On 26-04-2011 04:26, Tony Johansson wrote:
>> If I want to create an application for a multimedia store that can handle
>> selling/leasing music albums and film how can the inheritance look like.
>>
>> I have just thought something like this.
>> The class that is most general is an abstract class called Product.
>> Below this Product class I have two more abstract classes called Music
>> and
>> Film.
>> Below this Music I have a concreate class called CD and below
>> the Film class I have also a concrete CD class.
>>
>> Does this sounds reasonable ?
>
> (I assume that the class below Film is DVD not CD)
>
> Yes - the design makes some sense.
>
> It is a completely standard 1985-1995 design.
>
> :-)
>
> It can still be a valid design today.
>
> But I will recommend that you look at the functionality of
> those classes. Do they all have functionality that really
> belongs there?
>
> Or would a design with:
> - IProduct interface
> - Music and Film classes implementing IProduct
> - Music class has a property MediaType that can contain enum value
> MusicMediaType.CD
> - Film class has a property MediaType that can contain enum value
> FilmMediaType.DVD
> be better?
>
> Arne
>
>

One more suggestion about the design and that is to let the Product class
implement the interface IProduct.
Now I have three different design solutions for this inheritance.
I have somewhat hard to see the advantage and disadvantage for each
solution.

I just wonder what do you mean when you say
> But I will recommend that you look at the functionality of
> those classes. Do they all have functionality that really
> belongs there?

Can you give some example ?

//Tony

On 27-04-2011 04:14, Tony Johansson wrote:
> I just wonder what do you mean when you say
>> But I will recommend that you look at the functionality of
>> those classes. Do they all have functionality that really
>> belongs there?
>
> Can you give some example ?

Let us take your example.

Let us say that we consider Film class with two subclasses
DVD and BR.

The question is: will the DVD and BR class have any specific
functionality?

If not then drop them.

Note that whether there are specific functionality may
depend on the context.

For a store selling films there may be no difference in
functionality but for a factory producing them there may
be a difference.

Arne

"Arne Vajhøj" <(E-Mail Removed)> skrev i meddelandet
news:4db8ce1a$0$313$(E-Mail Removed)...
> On 27-04-2011 04:14, Tony Johansson wrote:
>> I just wonder what do you mean when you say
>>> But I will recommend that you look at the functionality of
>>> those classes. Do they all have functionality that really
>>> belongs there?
>>
>> Can you give some example ?
>
> Let us take your example.
>
> Let us say that we consider Film class with two subclasses
> DVD and BR.
>
> The question is: will the DVD and BR class have any specific
> functionality?
>
> If not then drop them.
>
> Note that whether there are specific functionality may
> depend on the context.
>
> For a store selling films there may be no difference in
> functionality but for a factory producing them there may
> be a difference.
>
> Arne
>
Just recap the multimedia store is about to use this functionalitty which is
selling/leasing music albums and film

I have three design alternatives for inheritance.
1.My first alternative. An abstract class Product that is most general and
below this I have Film and Music also abstract and below Film I have DVD and
below Music I have CD.
2.Your altetrnative
IProduct interface
- Music and Film classes implementing IProduct
- Music class has a property MediaType that can contain enum value
MusicMediaType.CD
- Film class has a property MediaType that can contain enum value
FilmMediaType.DVD
be better?
3.The same as 1 but in addition let Product implement interface IProduct

My first question is:
If I ask you which of these three alternatives should you use ?
I hope that you can give some motivation to your choice ?

If I ask myself if Film and Music will any specific functionality?
My second question is:
What does that mean actually ?
a. I mean you can buy both a DVD and a CD
b. You can lend a DVD and a CD back to the store after you have hired it.
The multimedia store might allow you to reserve.
c. So in that case you can reserve a DVD and a CD.

In all these three cases a,b and c it's the same with a CD and DVD.
But there is one specific difference and that is a DVD that you hire or buy
has only one movie but
if you buy or hire a CD there are many tracks on that CD.
Another difference is that a CD doesn't have genre like action, thriller,
drama and so on.
A third difference is the format of the film on a DVD and the format of the
tracks on a CD.
I track for music might have MP3 format.

My third question:
I have hard to see that anything should be placed in the concrete class CD
and DVD all data example that I found like
format, title, producer, name, playtime, buyprice, hireprice, number of
tracks on CD can be placed in Music or Film but in that case my CD and DVD
will be empty of data and that seems strange.
So can you give a single example of some data that is suitable to be placed
in the concrete class CD and DVD.

//Tony

On Thu, 28 Apr 2011 07:54:33 -0700, Peter Duniho
<(E-Mail Removed)> wrote:
- snip -
>
>More to the point, that may well not be a difference that matters in
>terms of your store's operation. Unless your store is going to take
>advantage of that information in some useful way, I see no reason to
>include it in your object model.
>
The format information is an attribute of the item, just as size and
color are attributes of a piece of clothing. These details are
important to the client's decision making process and shouldn't be
excluded. Other than that I agree.

- snip -
>
>It sounds to me as though you are leading yourself to abandoning the CD
>and DVD sub-class types. And in fact, that may make the most sense. A
>"Music" object might be a vinyl record, a CD, a magnetic tape, etc. but
>the media format doesn't affect the basic characteristics of the unit.
>It's probably fine to represent that format as a simple enumeration in
>the "Music" object.
>
In terms of the selling/leasing business rules, the format should be
unimportant. A catalog object could use a set of enumeration members
to describe available formats.

>Similarly, the "Film" object might be real film, video tape, DVD,
>Blu-ray, HD-DVD, etc. but again those are just formats for the same
>basic material. One more fundamental difference might be the film/tape
>vs random-access media formats like DVD and Blu-ray. The latter may
>well have properties that simply aren't found in the linear-access
>formats, and would justify a new data type to represent. But even
>there, until you have a _specific_ reason for separating those out (i.e.
>you know exactly what properties are salient and need to be
>represented), you may as well just stick with the basic "Film" object
>and an enumeration to represent the format.
>
The distinction between film and music should be unimportant to the
selling/leasing business rules because those are nothing more than
coarse-grained formats. I would consider these formats to be top level
catalog categories. Filtering by attributes such as genre or
fine-grained format will provide further catalog navigation.

Attributes such as formats and genre are details and abstractions
should not depend upon details. Abstractly the same business rules and
design patterns can be used for selling/leasing any type of object. My
client's web app for selling auto parts could be converted to sell
multimedia items by changing the catalog and catalog business rules.
Some revisions would have to be made to the UI but the app's design
patterns and back-end business rules would be unchanged.

regards
A.G.

On 28-04-2011 06:59, Tony Johansson wrote:
> "Arne Vajhøj"<(E-Mail Removed)> skrev i meddelandet
> news:4db8ce1a$0$313$(E-Mail Removed)...
>> On 27-04-2011 04:14, Tony Johansson wrote:
>>> I just wonder what do you mean when you say
>>>> But I will recommend that you look at the functionality of
>>>> those classes. Do they all have functionality that really
>>>> belongs there?
>>>
>>> Can you give some example ?
>>
>> Let us take your example.
>>
>> Let us say that we consider Film class with two subclasses
>> DVD and BR.
>>
>> The question is: will the DVD and BR class have any specific
>> functionality?
>>
>> If not then drop them.
>>
>> Note that whether there are specific functionality may
>> depend on the context.
>>
>> For a store selling films there may be no difference in
>> functionality but for a factory producing them there may
>> be a difference.
>>
> Just recap the multimedia store is about to use this functionalitty which is
> selling/leasing music albums and film
>
> I have three design alternatives for inheritance.
> 1.My first alternative. An abstract class Product that is most general and
> below this I have Film and Music also abstract and below Film I have DVD and
> below Music I have CD.
> 2.Your altetrnative
> IProduct interface
> - Music and Film classes implementing IProduct
> - Music class has a property MediaType that can contain enum value
> MusicMediaType.CD
> - Film class has a property MediaType that can contain enum value
> FilmMediaType.DVD
> be better?
> 3.The same as 1 but in addition let Product implement interface IProduct
>
> My first question is:
> If I ask you which of these three alternatives should you use ?
> I hope that you can give some motivation to your choice ?

You need the model that best fit your requirements.

>
> If I ask myself if Film and Music will any specific functionality?
> My second question is:
> What does that mean actually ?

That the classes will have fields/properties/methods that the
other classes does not have.

> a. I mean you can buy both a DVD and a CD
> b. You can lend a DVD and a CD back to the store after you have hired it.
> The multimedia store might allow you to reserve.
> c. So in that case you can reserve a DVD and a CD.
>
> In all these three cases a,b and c it's the same with a CD and DVD.

Yes. But none of these are really about the DVD and CD classes
but more about the Store class.

> But there is one specific difference and that is a DVD that you hire or buy
> has only one movie but
> if you buy or hire a CD there are many tracks on that CD.

There are usually always differences.

But are those differences relevant?

What does the store need to do different because of those differences
between film DVD's and music CD's?

If the answer is nothing, then you can use the same class.

> Another difference is that a CD doesn't have genre like action, thriller,
> drama and so on.

Music CD's have pop, rock, classic etc..

But does the app need to do anything with that information that makes
it necessary with different classes?

> A third difference is the format of the film on a DVD and the format of the
> tracks on a CD.
> I track for music might have MP3 format.

Same question.

> My third question:
> I have hard to see that anything should be placed in the concrete class CD
> and DVD all data example that I found like
> format, title, producer, name, playtime, buyprice, hireprice, number of
> tracks on CD can be placed in Music or Film but in that case my CD and DVD
> will be empty of data and that seems strange.

That is a very good indication that those classes should not exist!

> So can you give a single example of some data that is suitable to be placed
> in the concrete class CD and DVD.

I can not think of anything in this context.

Arne