r******r
发帖数: 700 | 1 Anyone is good at Design Pattern in Java here? Thanks.
As for the decorator pattern, what's the real benefit of using it? In this
example, why not simply let the specific classes, like "Milk/Whip/Sprinkle",
directly extend from the base class or interface "Coffee"?
Thanks.
// The Coffee Interface defines the functionality of Coffee implemented by
decorator
public interface Coffee {
public double getCost(); // returns the cost of the coffee
public String getIngredients(); // returns the ingredients of the coffee
}
// implementation of a simple coffee without any extra ingredients
public class SimpleCoffee implements Coffee {
public double getCost() {
return 1;
}
public String getIngredients() {
return "Coffee";
}
}
// abstract decorator class - note that it implements Coffee interface
abstract public class CoffeeDecorator implements Coffee {
protected final Coffee decoratedCoffee;
protected String ingredientSeparator = ", ";
public CoffeeDecorator(Coffee decoratedCoffee) {
this.decoratedCoffee = decoratedCoffee;
}
public double getCost() { // implementing methods of the interface
return decoratedCoffee.getCost();
}
public String getIngredients() {
return decoratedCoffee.getIngredients();
}
}
// Decorator Milk that mixes milk with coffee
// note it extends CoffeeDecorator
public class Milk extends CoffeeDecorator {
public Milk(Coffee decoratedCoffee) {
super(decoratedCoffee);
}
public double getCost() { // overriding methods defined in the abstract
superclass
return super.getCost() + 0.5;
}
public String getIngredients() {
return super.getIngredients() + ingredientSeparator + "Milk";
}
}
// Decorator Whip that mixes whip with coffee
// note it extends CoffeeDecorator
public class Whip extends CoffeeDecorator {
public Whip(Coffee decoratedCoffee) {
super(decoratedCoffee);
}
public double getCost() {
return super.getCost() + 0.7;
}
public String getIngredients() {
return super.getIngredients() + ingredientSeparator + "Whip";
}
}
// Decorator Sprinkles that mixes sprinkles with coffee
// note it extends CoffeeDecorator
public class Sprinkles extends CoffeeDecorator {
public Sprinkles(Coffee decoratedCoffee) {
super(decoratedCoffee);
}
public double getCost() {
return super.getCost() + 0.2;
}
public String getIngredients() {
return super.getIngredients() + ingredientSeparator + "Sprinkles";
}
}
public class Main
{
public static void main(String[] args)
{
Coffee c = new SimpleCoffee();
System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.
getIngredients());
c = new Milk(c);
System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.
getIngredients());
c = new Sprinkles(c);
System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.
getIngredients());
c = new Whip(c);
System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.
getIngredients());
// Note that you can also stack more than one decorator of the same
type
c = new Sprinkles(c);
System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.
getIngredients());
}
} | g*****g
发帖数: 34805 | 2 Check Java IO package to understand why decorator pattern is useful.
",
coffee
【在 r******r 的大作中提到】
: Anyone is good at Design Pattern in Java here? Thanks.
: As for the decorator pattern, what's the real benefit of using it? In this
: example, why not simply let the specific classes, like "Milk/Whip/Sprinkle",
: directly extend from the base class or interface "Coffee"?
: Thanks.
: // The Coffee Interface defines the functionality of Coffee implemented by
: decorator
: public interface Coffee {
: public double getCost(); // returns the cost of the coffee
: public String getIngredients(); // returns the ingredients of the coffee
| r******r
发帖数: 700 | 3 I saw an article that discusses 5 OOD principles, that might be of interest
to you as well:
"
SRP The Single Responsibility Principle A class should have one, and
only one, reason to change.
OCP The Open Closed Principle You should be able to extend a classes
behavior, without modifying it.
LSP The Liskov Substitution Principle Derived classes must be
substitutable for their base classes.
DIP The Dependency Inversion Principle Depend on abstractions, not
on concretions.
ISP The Interface Segregation Principle Make fine grained interfaces
that are client specific.
"
For details, see http://butunclebob.co/ArticleS.UncleBob.PrinciplesOfOod
It seems like it's difficult for most people to really put these principles
into practices in projects, either because they are unaware of these
fundamental concepts, or they are inexperienced. This may demonstrate one
aspect of differences between a good system designer/architect and an
average programmer. | r******r
发帖数: 700 | 4 Most programmers would have experiences of creating bad designed software.
But what is a "bad design"?
1. It is hard to change because every change affects too many other parts of
the system.
* Rigidity
2. When you make a change, unexpected parts of the system break.
*Fragility
3. It is hard to reuse in another application because it cannot be
disentangled from the current application.
* Immobility
Accordingly, what is a "good design":
* Flexibility
* Robust
* Reuse
Some interviewers also like to ask such a question.
interest
and
classes
【在 r******r 的大作中提到】
: I saw an article that discusses 5 OOD principles, that might be of interest
: to you as well:
: "
: SRP The Single Responsibility Principle A class should have one, and
: only one, reason to change.
: OCP The Open Closed Principle You should be able to extend a classes
: behavior, without modifying it.
: LSP The Liskov Substitution Principle Derived classes must be
: substitutable for their base classes.
: DIP The Dependency Inversion Principle Depend on abstractions, not
| B*****g
发帖数: 34098 | 5 我老板总是喜欢重复写同样的code，这样活显得多一些。我每次合理的提议都会被大多
数人拒绝。呵呵
of
not
【在 r******r 的大作中提到】
: Most programmers would have experiences of creating bad designed software.
: But what is a "bad design"?
: 1. It is hard to change because every change affects too many other parts of
: the system.
: * Rigidity
: 2. When you make a change, unexpected parts of the system break.
: *Fragility
: 3. It is hard to reuse in another application because it cannot be
: disentangled from the current application.
: * Immobility
| t*******e
发帖数: 684 | 6 Your boss never heard of the DRY (Don't repeat yourself) rule?
【在 B*****g 的大作中提到】
: 我老板总是喜欢重复写同样的code，这样活显得多一些。我每次合理的提议都会被大多
: 数人拒绝。呵呵
:
: of
: not
| B*****g
发帖数: 34098 | 7 俺不知道，我就知道如果如果不重复，俺们组起码裁60%的人。
大多
【在 t*******e 的大作中提到】
: Your boss never heard of the DRY (Don't repeat yourself) rule?
|
|
