Abstract class / interface question
I need to manipulate references to two subclasses (let's call them Guitar and Bass, derived from Instrument). I thought about coding Instrument as an interface, but I have a problem.
I have fields in Guitar and Bass (lets call them brand and price) that I would like to access without having to write access methods for all of them. I want to call a constructor on either, which should appear like this: new Guitar(String brand, Double price). If I need variables to be a part of the interface, am I forced to use an abstract class instead?
I'm aware that interfaces can have variables, but that they must be static and final. What I'm looking for is a way for the interface to force any implementations to have a variable by that name (ie price, brand), but without actually having the value in the interface. Is this something that only an abstract class can do?
[886 byte] By [
corrosivea] at [2007-10-3 10:08:27]
it's not something you can do with an interface, no. what you're talking about is providing some default implementation. implementation isn't restricted to methods. you need a base class, yes
Ok, so knowing that I've got to use an abstract class at this point, I have another question.
If I'm going to use a constructor to create Bass and Guitar object, and I need to pass arguments through the constructor (like new Guitar(String brand, Double price) ), will they automatically inheret all of the constructors from the superclass?
So lets say Instrument has a constructor that's like this Instrument(String brand, Double price). Will Guitar and Bass automatically inheret that constructor so that I can call Guitar(String brand, Double price), or do I specifically have to define a constructor in the Guitar class in this fashion:
public Guitar(String brand, Double price) {
super(brand, price);
}
Please advise. Thanks!
well, why don't you try it? but, no. they won't inherit the constructors, you will need to explicitly write the constructors in the subclasses
This isn't a patterns question. This is Java -101.%
might not be a patterns question, but it is a design question. of sorts
this poor thread keeps getting cut down in the prime of it's irrelevance!
> What I'm looking for is a way for the interface to force any implementations to have a variable by that name (ie price, brand), but without actually having the value in the interface.
Interfaces are a contract for behavior. You can imply state, but you can't mandate like you're asking. Keep refining your design... :o)
~
> this poor thread keeps getting cut down in the prime> of it's irrelevance!Sucked into that swirling vortex of doom known as "The daFeiniverse"? yawmark (<-- listening to the big flushing sound)
> > What I'm looking for is a way for the interface
> to force any implementations to have a variable by
> that name (ie price, brand), but without actually
> having the value in the interface.
>
> Interfaces are a contract for behavior. You can imply
> state, but you can't mandate like you're asking. Keep
> refining your design... :o)
>
> ~
the OP got what he wanted and left long ago, and was quite gracious and polite about it, too. which was nice
if you do come back, corrosive, we did get into a dialog about use of String as an all-purpose type ( you used it as a Brand ) I'd quite like to continue that, if you don't mind
> the OP got what he wanted and left long ago, and was> quite gracious and polite about it, too. which was niceAh, thanks. It's hard to keep up, what with all the pollution. :o)~
> > the OP got what he wanted and left long ago, and
> was
> > quite gracious and polite about it, too. which was
> nice
>
> Ah, thanks. It's hard to keep up, what with all the
> pollution. :o)
>
> ~
pollution I keep getting sucked into, despite my best efforts :-/ grrrrrrr
> if you do come back, corrosive, we did get into a
> dialog about use of String as an all-purpose type (
> you used it as a Brand ) I'd quite like to continue
> that, if you don't mind
I didn't read the original post in depth but it appeared you example was suggesting that a string was being used as a brand name and nothing more.
Which is entirely appropriate.
Perhaps I misread your example or you meant to imply additional functionality for each type.
> > if you do come back, corrosive, we did get into a
> > dialog about use of String as an all-purpose type
> (
> > you used it as a Brand ) I'd quite like to
> continue
> > that, if you don't mind
>
> I didn't read the original post in depth but it
> appeared you example was suggesting that a string was
> being used as a brand name and nothing more.
>
> Which is entirely appropriate.
>
> Perhaps I misread your example or you meant to imply
> additional functionality for each type.
'twas corrosive's suggestion. not a brand name, but to the brand itself. I argued that Brand was a candidate for a type in it's own right, rather than merely being some string data. although he intended (for now) for Brand to be it's name, I think there's still a risk of some arbitrary data, perhaps a mis-spelling, to make its way into somewhere he'd expect a known brand to be. much as in the case of static ints being used as enums, and people simply not using the constants and falling back on the raw int, only to find that the underlying implementation changed and, say, '6' no longer representing the state it once did. how often have you seen people, for instance use the int literal '2' instead of Calendar.MARCH? Strings, I feel, are open to the same use/abuse when used as a general-purpose simple type.
either argument is equally valid, I guess, if you're fairly confident there's no danger of abuse. I'd prefer to leverage type-safety, all the same, since it's there. his argument was that using a string kept the design simpler. to me, the burden of an extra class would be worth the safety
what's your stance?
>
> 'twas corrosive's suggestion. not a brand
> name, but to the brand itself. I argued that
> Brand was a candidate for a type in it's own right,
> rather than merely being some string data. although
> he intended (for now) for Brand to be it's
> name, I think there's still a risk of some arbitrary
> data, perhaps a mis-spelling, to make its way into
> somewhere he'd expect a known brand to be. much as in
> the case of static ints being used as enums, and
> people simply not using the constants and falling
> back on the raw int, only to find that the underlying
> implementation changed and, say, '6' no longer
> representing the state it once did. how often have
> you seen people, for instance use the int literal '2'
> instead of Calendar.MARCH? Strings, I feel, are open
> to the same use/abuse when used as a general-purpose
> simple type.
>
That depends on the source of the data. I wouldn't normally expect that a system for guitars would be hard coding the type data but would rather be getting it from a data store like a database. Validation, if done, would be based on an enumerated list from the data store as well.
Alternatively if I it was a static type then I might or might not use Strings. Although I would probably end up code gen'*** it anyways. If I did use Strings then there would be validation which would deal with incorrect types. Whether I used Strings or not would depend on how the type information was being used.
Adding a bit more, I am probably more likely to use an enumerated type for something derived from implementation/design than something derived from business cases.
> >
> > 'twas corrosive's suggestion. not a brand
> > name, but to the brand itself. I argued
> that
> > Brand was a candidate for a type in it's own
> right,
> > rather than merely being some string data.
> although
> > he intended (for now) for Brand to be it's
> > name, I think there's still a risk of some
> arbitrary
> > data, perhaps a mis-spelling, to make its way into
> > somewhere he'd expect a known brand to be. much as
> in
> > the case of static ints being used as enums, and
> > people simply not using the constants and falling
> > back on the raw int, only to find that the
> underlying
> > implementation changed and, say, '6' no longer
> > representing the state it once did. how often have
> > you seen people, for instance use the int literal
> '2'
> > instead of Calendar.MARCH? Strings, I feel, are
> open
> > to the same use/abuse when used as a
> general-purpose
> > simple type.
> >
>
> That depends on the source of the data. I wouldn't
> normally expect that a system for guitars would be
> hard coding the type data but would rather be getting
> it from a data store like a database. Validation, if
> done, would be based on an enumerated list from the
> data store as well.
>
> Alternatively if I it was a static type then I might
> or might not use Strings. Although I would probably
> end up code gen'*** it anyways. If I did use Strings
> then there would be validation which would deal with
> incorrect types. Whether I used Strings or not would
> depend on how the type information was being used.
actually, the world of guitars is a rather neat example of where a string isn't appropriate as a Brand type. in the past, I've owned 2 guitar amps, made by entirely unrelated companies in different countries, with not even a passing resemblance to each other in tone, appearance or price, both branded as "Park". one was produced by a manufacturer named Park, the other Park is a brand owned by Marshall Amplifiers (named after Jim Marshall's wife, fact fans), and essentially a budget range of Marshalls. were the two represented merely by strings, confusion could easily arise. granted, there are workarounds for that, but the type safety of a Brand class would negate any need for such workarounds
as you've indicated, each case needs consideration on it's own merits, but I'd be wary of choosing strings simply for convenience
>
> actually, the world of guitars is a rather neat
> example of where a string isn't appropriate as a
> Brand type. in the past, I've owned 2 guitar amps,
> made by entirely unrelated companies in different
> countries, with not even a passing resemblance to
> each other in tone, appearance or price, both branded
> as "Park". one was produced by a manufacturer named
> Park, the other Park is a brand owned by Marshall
> Amplifiers (named after Jim Marshall's wife, fact
> fans), and essentially a budget range of Marshalls.
> were the two represented merely by strings, confusion
> could easily arise. granted, there are workarounds
> for that, but the type safety of a Brand class would
> negate any need for such workarounds
>
Ok - but again I would still probably favor creating a data store for this and let the business users themselves decide how to differentitate that. One way would of course be to add a manufacturer field as well.
Given that it was coming from a data store then I would be really unlikely to implement this particular field as anything but a string.
Note that using a data store doesn't limit the functionality aspect. That could either be hard coded or via a plug in. Note of course that the brand name itself does not define the functionality but rather the business object itself does.
this thread got trimmed again? poor thing. and now look, I'm anthropomorphising threads :-( it's a slippery slope
