Here I would like to put my point about this design pattern.
During the interviews, I have seen people telling in this pattern we use the object of the base class in our method & then add more functionality in that.
While I say that if we are looking to decorate some base class then we should accept the object of base class & provide the overridden method with added functionalities, but here we will not change the type & can pass this new object to any method accepting the objects of base class but in other case you are changing the type, if you are not in the same hierarchy of the base class or added some new methods not visible to base class..
So for me if you are extending any class & overriding any of the parent class's method then you are decorating it.
But keep in mind, for me there is also a constraint while decorating the objects/classes by extending other class, like if you add a new method in your class but this method will not be visible to the parent class & the receiver of the object of your class must be aware of your class & has to type cast that object to your class to use that new method.
And, as given in documents for decorator, that will not be a transparent decoration & will not even work when you are intercepting some calls & trying to introduce the objects of your class replacing original objects.
Also if you are extending the parent class to do any decoration then it will be compile time, so to avoid this in decorator pattern it is suggested to implement the parent interface. Though I don't see much improvement in this also as I need to create the same number of classes, rather I have to maintain one class decorating the objects of the parent class.
This design pattern seems to be confusing as I have seen that people saying that in this they will have the object of the parent class & will also add new method/s in their class & then will return the objects of their custom class or something like this. But I feel it is more on the wrapping the objects, not looking like decorating the objects, even if we do implement the root interface.
And I don't think it as a good decorator pattern implementation, even not a decorator in true sense.
To implement such hypothetical/imaginary pattern, people add an interface & then create various implementations of that interface but I can't understand when the provided object is being decorated, rather all its properties are copied to the object of your decorator class. And you can't even assign the object of your decorator to the variable of type of base class, the object of which you are trying to decorate. Then what is the use?
public class MainClass {
public static void main(String[] args) {
Base b = new Base();
b.setEmpId(1);
b.setName("Nitin");
printDetails(b);
b = new Decorator(b, "India");
printDetails(b);
}
public static void printDetails(Base b) {
System.out.println(b.getDetails(1));
}
}
class Base {
private int empId;
private String name;
public int getEmpId() {
return empId;
}
public void setEmpId(int empId) {
this.empId = empId;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
String getDetails(int id) {
if(id != 0)
return name + " with ID : " + empId;
return null;
}
}
class Decorator extends Base {
private Base b;
private String country;
public Decorator(Base b, String city) {
this.b = b;
this.country = city;
}
@Override
public String getDetails(int id) {
if(id != 0) {
String result = b.getEmpId() + " is the id of " + b.getName() + " who lives in " + country;
return result;
}
return "No data found";
}
}
You views will be appreciated & have given one simple sample code above which is decorator as per my understanding. But surely would like to have a healthy discussions around these patterns.
www.avajava.com/tutorials/lessons/decorator-pattern.html
www.journaldev.com/1540/decorator-design-pattern-in-java-example
During the interviews, I have seen people telling in this pattern we use the object of the base class in our method & then add more functionality in that.
While I say that if we are looking to decorate some base class then we should accept the object of base class & provide the overridden method with added functionalities, but here we will not change the type & can pass this new object to any method accepting the objects of base class but in other case you are changing the type, if you are not in the same hierarchy of the base class or added some new methods not visible to base class..
So for me if you are extending any class & overriding any of the parent class's method then you are decorating it.
But keep in mind, for me there is also a constraint while decorating the objects/classes by extending other class, like if you add a new method in your class but this method will not be visible to the parent class & the receiver of the object of your class must be aware of your class & has to type cast that object to your class to use that new method.
And, as given in documents for decorator, that will not be a transparent decoration & will not even work when you are intercepting some calls & trying to introduce the objects of your class replacing original objects.
Also if you are extending the parent class to do any decoration then it will be compile time, so to avoid this in decorator pattern it is suggested to implement the parent interface. Though I don't see much improvement in this also as I need to create the same number of classes, rather I have to maintain one class decorating the objects of the parent class.
This design pattern seems to be confusing as I have seen that people saying that in this they will have the object of the parent class & will also add new method/s in their class & then will return the objects of their custom class or something like this. But I feel it is more on the wrapping the objects, not looking like decorating the objects, even if we do implement the root interface.
And I don't think it as a good decorator pattern implementation, even not a decorator in true sense.
To implement such hypothetical/imaginary pattern, people add an interface & then create various implementations of that interface but I can't understand when the provided object is being decorated, rather all its properties are copied to the object of your decorator class. And you can't even assign the object of your decorator to the variable of type of base class, the object of which you are trying to decorate. Then what is the use?
public class MainClass {
public static void main(String[] args) {
Base b = new Base();
b.setEmpId(1);
b.setName("Nitin");
printDetails(b);
b = new Decorator(b, "India");
printDetails(b);
}
public static void printDetails(Base b) {
System.out.println(b.getDetails(1));
}
}
class Base {
private int empId;
private String name;
public int getEmpId() {
return empId;
}
public void setEmpId(int empId) {
this.empId = empId;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
String getDetails(int id) {
if(id != 0)
return name + " with ID : " + empId;
return null;
}
}
class Decorator extends Base {
private Base b;
private String country;
public Decorator(Base b, String city) {
this.b = b;
this.country = city;
}
@Override
public String getDetails(int id) {
if(id != 0) {
String result = b.getEmpId() + " is the id of " + b.getName() + " who lives in " + country;
return result;
}
return "No data found";
}
}
You views will be appreciated & have given one simple sample code above which is decorator as per my understanding. But surely would like to have a healthy discussions around these patterns.
www.avajava.com/tutorials/lessons/decorator-pattern.html
www.journaldev.com/1540/decorator-design-pattern-in-java-example