No, they're TIRES. Sorry, culture bashing. I kinda like Tyres. I'm in Pennsylvania - American coal country - working with a bunch of Londoners these days. Anyhow, a couple things. You have an ArrayList, and you call add() but you have to find something to add. Maybe you wanted to add the String with the brand name? So your methodA() could say l.add(name). Next, each instance of the Tyres class has its own list object. And you only add to the list once when the constructor calls methodA. So you're only going to add one name to the list in each instance. You'll need a different design if you want the list to capture all the brand names in one list. One trick would be to make the ArrayList variable "static". That means the variable belongs to the class instead of to the instance, so you get only one ArrayList no matter how many Tyre objects you create. All instances kind of share the one ArrayList. What would display() do in that case? When you create "Goodyear" it would display "Goodyear". When you create "Sprint" it would display "Goodyear" and "Sprint". Would that be right? I have no idea because it's your program after all. Is that leading you the right direction? If it's not meeting your needs, maybe back up and talk about the requirements - desired behavior - a bit more. Finally, trying not to be too picky here, but "l" doesn't sing to me as a variable name. Back to the requirements topic, can you think of a name that helps me know what we're listing? Have fun exploring Java. Come back often if you need help. Cheers!
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
First off, I'm not sure how you got this to compile. The List class doesn't have an "add()" method...you have to pass something in to that method to add something ot the list. You can't just call "add". Secondly, I have a bit of a problem with the inheritance, but to be fair whether or not this is correct is completely dependent on the application. For most purposes that I can think of, though, a "wheel" is the part that connects to the axle of a car and provides a mounting point for a "tire", the rubber, air-filled encasing that cushions the vehicle. These are two different things altogether, a tire in my mind does not have the is-a relationship with wheel. Depending on your point of view, a tire "has-a" wheel, or a wheel "has-a" tire, but neither is the other. Question: for the purposes of your application, do these two objects live and die together? Is it possible to change a tire in your app without changing the wheel? If so, then the wheel might live to see many tires over its lifetime and it wouldn't make sense to destroy both objects simultaneously (which is absolutely necessary if you're going to make one inherit from the other...in one sense the "wheelness" of the object and the "tireness" of it are so tightly married they form a single object). Also, I'd shy away from creating "plural" classes. You have a Wheels object and a Tyres object. Why not just create a class that represents a wheel and a tire, and instantiate as many as you need? Why one class that needs to be able to represent more than one tire or wheel? How many wheels does one Wheels instance represent? It just adds confusion. Instead, try:
Notice I've kept things very simple. Each class represents a single object, and now I'm free to use these elemental components to build more complicated structures. Say, for instance, I wanted to represent an axle and a car:
Note that both Car and Axle have constructors that force callers to create them with Axles and Wheels, respectively (unless the caller creates a new Car(null,null), in which case we figure he knows what he's doing and we provide him all the rope he needs...). I made this decision because it seems to me that a Car without axles and an Axle without two mount points for tires are quite useless indeed. On the other hand, a wheel does not have to come attached to a tire. These are purely arbitrary decisions I made based upon an imagined application, and would only be defensible choices for that particular imagined application. If you were writing an app that didn't require tracking tires separate from their wheels, then you might make a different choice. My imagined application is software that runs an auto manufacturing plant, and at a manufacturing plant a car will definitely not be considered "done" until it has axles and wheels, but the customer may have a choice of different tires that could be installed (a sport package might require low profile racing tires, for instance). So, it does not detract from the "car-ness" of the car to build it without tires and simply install those later. Now we can assemble a car:
You get the point. Now you might also notice how tiresome (sorry, had to) it is to make all those method calls. Glad you noticed it--I was getting tired of typing. So, to address this, you could add a method to the Car class that takes four tires and does the setting for you (I'll take it to the next logical step too):
Now, the code in the AutoPlant class becomes much simpler: