Reputation: 459
I have got a question.
Should I create getter and setter methods inside abstract class? The below example contains these methods inside abstract class which is extended by Individual class. Is it a good practice to have different variety on methods inside abstract class? Should I be overriding those methods inside Individual class? However it doesn't make sense for me to override those as these will not do anything different, just set and get different attributes. Any advice?
public abstract class Human {
private String name;
private String surname;
public Human(String name, String surname) {
this.name = name;
this.surname = surname;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getSurname() {
return surname;
}
public void setSurname(String surname) {
this.surname = surname;
}
}
public class Individual extends Human{
private String dob;
public Individual(String name, String surname, String dob) {
super(name, surname);
this.dob = dob;
}
public String getDob() {
return dob;
}
public void setDob(String dob) {
this.dob = dob;
}
public void viewIndividual(){
System.out.println("First name of individual is: " + getName());
System.out.println("Surname of individual is: " + getSurname());
System.out.println("Date of birth of individual is: " + getDob());
}
}
Upvotes: 0
Views: 1193
Reputation: 10964
Should I create getter and setter methods inside abstract class?
Yes, if a method is common to most expected implementations of an abstract class, it's perfectly fine to implement those methods in the abstract class. If it's really good to have getters and setters for the properties of your Human
, it hard to say. The way you're currently using it, it doesn't make much sense, as you're mixing behavior aspects (viewIndividual) with data aspects (getters and setters) in one class. Given the code above you would be fine with protected members in the abstract class, and potentially setters to avoid code duplication in the implementations. But if you want to use your objects as Java-Beans, it's fine.
Is it a good practice to have different variety on methods inside abstract class?
You mean both, abstract and non-abstract methods? Yes, this is pretty standard. Take this example:
public abstract class Example {
public final void publicMethod() {
// do some preparations
internalMethod();
// do some cleanup
}
protected abstract void internalMethod();
}
Consumers of implementations of Example
will only be able to access publicMethod
and it is guaranteed that all needed preparations and cleanup tasks are executed without repeating this code over and over again in the implementations of Example
as only internalMethod
needs to be overridden.
Should I be overriding those methods inside Individual class?
No, definitively not. At least as long as you don't add additional functionality to the methods, abstract methods should not be overridden just for implementing them inside the instantiatable class.
In general you should be careful with inheritance as code tends to become very hard to understand, if you implement something in a deep type hierarchy. IMHO hierarchies start to become hard to use with a hierarchy level of 4-5 already, but this is probably heavily opinion based. There is the rule to prefer composition over inheritance to avoid over-exhaustive use of inheritance for simple utility stuff.
Upvotes: 2