We Keep Coding

Error when extending from abstract parent class

Error
public Cat (String nm, int legs, String sd, String col)
For this constructor I got following compiler error:
constructor Animal in class Animal cannot be applied to given types;
required: String, int
found: no arguments
reason: actual and formal arguments lists differ in length
Code
The parent class is right below the child class.
public class Cat extends Animal {
private String sound;
private String colour;
public Cat (String nm, int legs, String sd, String col) {
nm = super.getName();
legs = super.getNumOfLegs();
sound = sd;
colour = col;
}
public abstract class Animal {
protected String name;
protected int numOfLegs;
public Animal() {
}
public Animal(String nm, int legs) {
name = nm;
numOfLegs = legs;
}
public String getName() {
return name;
}
public int getNumOfLegs() {
return numOfLegs;
}
public abstract String display();
}
}
Should the parent abstract class be placed in a separate file instead?
I've tried that initially but it returned way more errors than it did now, especially from the abstract method display().
What is causing the error?

There are a couple of things you should change.
First of all, it is the best way to put the super class into a separate file. If you want to keep in one file you need drag it out of the Cat class and remove the scope (not public or private). But this is not a good coding style for a super class.
The next thing is, with the name/nm and legs/numOfLegs. Either you call the super constructor and provide the two variables (see my example) or you use name = nm; and numOfLegs = legs;
You should also reconsider if the name and numOfLegs varialbes need to be protected or if is fine to provide the access only through the getter.
If the number of legs, the name, sound and color will not change you could also make them immutable (with the key word final, e.g. private final String sound). If not you can make them accessible with a setter.
Finally you need to implement the abstract method in the Cat class...
public class Cat extends Animal {
private String sound;
private String colour;
public Cat(String nm, int legs, String sd, String col) {
super(nm, legs);
sound = sd;
colour = col;
}
#Override
public String display() {
return null;
}
}
abstract class Animal {
protected String name;
protected int numOfLegs;
public Animal(String nm, int legs) {
name = nm;
numOfLegs = legs;
}
public String getName() {
return name;
}
public int getNumOfLegs() {
return numOfLegs;
}
public abstract String display();
}

Java Inheritance: Restrict List to Subclass Objects

Let's assume I have 3 classes: Car, Convertible and Garage.
Car:
public class Car {
private String name;
private String color;
public Car(String name, String color) {
this.name = name;
this.color = color;
}
//Getters
}
Convertible inherits from Car:
public class Convertible extends Car{
private boolean roof;
public Convertible(String name, String color, boolean roof) {
super(name, color);
this.roof = roof;
}
public boolean isRoof() {
return roof;
}
}
Garage stores a list of Cars:
public class Garage {
private int capacity;
private List<Car> cars = new LinkedList<Car>();
//Setter for capacity
}
How could I create a subclass of Garage called ConvertibleGarage that can only store Convertibles?

You could use a little bit of generics:
public class Garage<T extends Convertible> {
private int capacity;
private List<T> cars = new LinkedList<T>();
public Garage(int capacity) {
this.capacity = capacity;
}
}
This means when you instantiate a Garage you now have to include a parameter type that is a Convertible or child of it.
Garage<Convertible> cGarage = new Garage<>();

Generics will help here.
Make the Garage class generic Garage<T extends Car>, where a T is a car type it can store. Rewrite the cars list to a generic view List<T> as well.
Then, a Garage<Convertible> is going to be your "ConvertibleGarage".

You don't really need to make a second Garage class, you can use Generics :
public class Garage<T extends Car> {
private int capacity;
private List<T> cars;
public Garage() {
this.cars = new LinkedList<>();
}
public static void main(String[] args) {
Garage<Convertible> garConv = new Garage<>();
garConv.cars.add(new Convertible("", "", true));
Garage<Car> garCar = new Garage<>();
garCar.cars.add(new Car("", ""));
}
}
With this only class you can have a garage for car and a one for convertible

As the other answers have explained, you solve your problem by making your Garage class generic - and therefore allowing any instance of Garage to deal with exactly one kind of cars.
But what is missing so far: this is not "an option" to solve your problem - this is simply "the way to go here". Your idea of using inheritance is "plain wrong". Meaning: when people start with object oriented design, they assume that inheritance is the answer to everything. And actually that is not true. You are rather careful about creating an extends relation between two classes.
And especially when talking about containers - classes that "contain" other objects - then generics is your first thought!

How to create an object from a subclass in Java

So I have this class:
public class parent {
private int id;
private int row;
public parent(int id,int row) {
this.id=id;
this.row=row
}
}
and then I have this class which extends parent
public class son extends parent {
public son(int id,int row) {
super(id,son);
}
}
the question is how do i create an object for class son.Do I have to call it like this:
son x=new son(int id,int row);
I am really confused.

Yep, you're just about spot on! To be absolutely clear, you wouldn't use the type of id and row in calling the constructor, you would just give values of that type.
So this is wrong:
son x = new son(int 5, int 6); //Incorrect
And this is correct:
son x = new son(5, 6); //Correct
You can also pass variables of the correct type, like this:
int id = 5;
int row = 6;
son x = new son(id, row);
Also, I just noticed that you wrote:
public class parent {
private int id;
private id row;
//....
instead of
public class parent {
private int id;
private int row; //Note the change id --> int here
//....
If this was a typo, don't worry about it. Otherwise you may have a conceptual misunderstanding. id isn't a type, but int is. So we can't declare row as an id, but we can declare it as an int. Unlike in C and friends you can't create synonyms of types with a typedef, so you're stuck with the base types (int, boolean, etc).
Since it appears that you're new to Java, the convention is for classes to have Pronoun Case (capitalized first letter of each word) names. Thus it would be better style to use the following formatting for your classes:
public class Parent {
private int id;
private int row;
public Parent(int id,int row) {
this.id=id;
this.row=row
}
}
public class Son extends Parent {
public Son(int id,int row) {
super(id,son);
}
}
public class ThisClassHasManyWordsInItAndItShouldBeFormattedLikeThis {
//.....
}
Which then makes the construction:
Son x = new Son(5,6);
Once you've constructed a Parent object like Parent p = new Parent(4,5);, there's no way to change p into a Son. It's not possible. However, you can copy p into a new Son, and you can make some modifications to the classes to make it easier to make these copies:
public class Parent {
private int id;
private int row;
public Parent(int id,int row) {
this.id=id;
this.row=row
}
public int getId() {
return id;
}
public int getRow() {
return row;
}
}
public class Son extends Parent {
public Son(int id,int row) {
super(id,son);
}
public Son(Parent p) {
super(p.getId(), p.getRow());
}
}
Now we can create a Parent, and copy it into a new Son:
Parent p = new Parent(4,5);
Son s = new Son(p); //will have id of 4 and row of 5
It's worth noting that while all this is well and good for learning how class extension works, you're not actually using it quite correctly. By saying Son extends Parent, you're saying that Son is a type of Parent, which isn't true in the elementary school model of a Family. A better way to model a family would probably be:
public class Person {
private Person mother;
private Person father;
public Person(Person mother, Person father) {
this.mother = mother;
this.father = father;
}
}
If you're still looking for a way to include class extension, then Man and Woman make sense as extensions of class Person, because a Man is a type of Person. (i.e. All men are people, not all people are men).
public class Person {
private Man father;
private Woman mother;
public Person(Man father, Woman mother) {
this.father = father;
this.mother = mother;
}
}
public class Man extends Person {
public Man(Man father, Woman mother) {
super(father, mother);
}
}
public class Woman extends Person {
public Woman(Man father, Woman mother) {
super(father, mother);
}
}

How to convert an object from class to superclass

I have to model breakwater that controls permissions in certain coast. My solution implements a class "Ship" and classes "OilShip", "FishingShip" and "CarriageShip", I used inheritance and made
public class OilShip extends Ship{
...
}
public class FishingShip extends Ship{
...
}
public class CarriageShip extends Ship{
...
}
In another class I have Ship ship=new Ship(...); and I'd like to somehow make an Oilship into Ship, i.e.
public Class Abcd{
Ship ship;
public Abcd(OilShip oship){
ship=oship; //*************
}
}
There seems to be a problem with the code, please tell me.

Make sure you call the superclass' constructor inside your subclasses' constructors.
This solution works fine for me:
public class Ship {
private String name;
private int weight;
public Ship(String name, int weight) {
this.name = name;
this.weight = weight;
}
}
class OilShip extends Ship {
private int oilCapacity;
public OilShip(int oilCapacity, String name, int weight) {
super(name, weight);
this.oilCapacity = oilCapacity;
}
}
class FishingShip extends Ship {
private int fisherMen;
public FishingShip(int fisherMen, String name, int weight) {
super(name, weight);
this.fisherMen = fisherMen;
}
}
class CarriageShip extends Ship {
private int containers;
public CarriageShip(int containers, String name, int weight) {
super(name, weight);
this.containers = containers;
}
}
As mentioned before, Java-classes should always be given a name, where the first character is in UPPERCASE and the same with each new word --> CamelCase
You don't need different constructors. The awesome thing behind using inheritance here, is, that no matter what subclass from the superclass "Ship" you put into your constructor in "abcd", it will be accepted:
public class Abcd {
private Ship ship;
public Abcd(Ship ship){
this.ship = ship;
}
}

Builder Pattern: which variant is preferred? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I was going through Effective Java book , and creating notes for my future reference ,
i came across Builder Pattern.
Well i understood what it is and how its suppose to be used.In the process i created a two example variations of the builder pattern.
I would need help in listing down the differences and the advantage each has?
Well i certainly noticed that , Example 1 exposes less methods , there by less restrictive and
more generic , there by allowing it to be used more flexibly.
Please point out other things i have missed?
Example 1
package item2;
/**
* #author Sudhakar Duraiswamy
*
*/
public class Vehicle {
private String type;
private int wheels;
interface Builder<T>{
public T build();
}
public static class CarBuilder implements Builder<Vehicle>{
private String type;
private int wheels;
CarBuilder createVehicle(){
this.type= "Car";
return this;
}
CarBuilder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle build(){
Vehicle v = new Vehicle();
v.type = type;
v.wheels = wheels;
return v;
}
}
public static class TruckBuilder implements Builder<Vehicle>{
private String type;
private int wheels;
TruckBuilder createVehicle(){
this.type= "Truck";
return this;
}
TruckBuilder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle build(){
Vehicle v = new Vehicle();
v.type = type;
v.wheels = wheels;
return v;
}
}
public Vehicle(){
}
public static void main(String[] args) {
//This builds a car with 4 wheels
Vehicle car = new Vehicle.CarBuilder().createVehicle().addWheels(4).build();
//THis builds a Truck with 10 wheels
Vehicle truck = new Vehicle.TruckBuilder().createVehicle().addWheels(10).build();
}
}
Example 2
package item2;
/**
* #author Sudhakar Duraiswamy
*
*/
public class Vehicle2 {
private String type;
private int wheels;
interface Builder<T>{
public T build();
public String getType();
public int getWheels() ;
}
public static class CarBuilder implements Builder<Vehicle2>{
private String type;
private int wheels;
public String getType() {
return type;
}
public int getWheels() {
return wheels;
}
CarBuilder createVehicle(){
this.type= "Car";
return this;
}
CarBuilder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle2 build(){
return new Vehicle2(this);
}
}
public static class TruckBuilder implements Builder<Vehicle2>{
private String type;
private int wheels;
public String getType() {
return type;
}
public int getWheels() {
return wheels;
}
TruckBuilder createVehicle(){
this.type= "Truck";
return this;
}
TruckBuilder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle2 build(){
return new Vehicle2(this);
}
}
public Vehicle2(Builder<? extends Vehicle2> builder){
Vehicle2 v = new Vehicle2();
v.type = builder.getType();
v.wheels = builder.getWheels();
}
public Vehicle2(){
}
public static void main(String[] args) {
//This builds a car with 4 wheels
Vehicle2 car = new Vehicle2.CarBuilder().createVehicle().addWheels(4).build();
//THis builds a Truck with 10 wheels
Vehicle2 truck = new Vehicle2.TruckBuilder().createVehicle().addWheels(10).build();
}
}

None of the above.
The first one doesn't allow building an immutable Vehicle, which is often why the Builder pattern is used.
The second example is a variation of the first one which allows getting information from the builder using additional getter methods. But those those methods aren't used anywhere, except in the Vehicle constructor, which has access to the builder fields directly. I don't see the point in adding them.
I see two more important things to improve:
The two builder types do exactly the same thing. There's no need for two types. A single one is sufficient.
What the createVehicle() method does should be done by the builder constructor. If you construct a CarBuilder, it's obviously to build a car, so the type of the vehicle should be set as soon as the builder is constructed. Here's how I would write it:
.
public final class Vehicle {
private final String type;
private final int wheels;
private Vehicle(Builder builder) {
this.type = builder.type;
this.wheels = builder.wheels;
}
public static Builder carBuilder() {
return new Builder("car");
}
public static Builder truckBuilder() {
return new Builder("truck");
}
public static class Builder {
private final String type;
private int wheels;
private Builder(String type) {
this.type = type;
}
public Builder addWheels(int wheels){
this.wheels = wheels;
return this;
}
public Vehicle build() {
return new Vehicle(this);
}
}
public static void main(String[] args) {
Vehicle car = Vehicle.carBuilder().addWheels(4).build();
Vehicle truck = Vehicle.truckBuilder().addWheels(10).build();
}
}

There is a third variant too, with less code:
Instead of having their own instance fields the builders could also mutate the state of Vehicle. Inner classes can write private members of their outer class:
class Vehicle {
private int wheels;
private Vehicle() {}
public static class Builder {
private boolean building = true;
private Vehicle vehicle = new Vehicle();
public Builder buildWheels(int wheels) {
if(!this.building) throw new IllegalStateException();
this.vehicle.wheels = wheels;
return this;
}
public Vehicle build() {
this.building = false;
return this.vehicle;
}
}
}
Since the fields are private and you allow it to be build only once (building flag), built Vehicle instances are still immutable to consumers even though the fields cannot be final anymore (no more realio-trulio immutability, see Eric's blog article which is on C# but the concepts are similar).
You need to be more careful as non-final fields do not have to be initialized during object construction (enforced by the compiler) and you must check the building state carefully. You do however save a full extra-copy of all instance fields. In general, this is useful if you have a rather large set of instance variables that are built with rather few methods, where each method builds a few fields at once.
I know this does not point out any advantages or drawbacks of your approaches. However, this approach can save a lot of extra code if you do not need the fields to be final.