Return to Answer

No. There is no call for an AbstractDecorator. Decorators typically use composition and delegation anyway.

If you're a fan of UML these diagrams might help.

See? No abstract decorator. Component might be abstract but it has no idea the decorator exists. The Decorator both implements the Component interface and accepts a Component. That way it can pretend to be one and pass on what it's told to do to the Component it holds. Why? So it doesn't have to do that work itself. The Decorator can pretend to be both the Component and the Client while making them still do their work. This way all it has to do is add whatever behavior it was created to add.

But let's try an example from the real world.

You're looking at two gas pump credit card readers. Except the one on the left has a skimmer attached. Use either one and you can get gas. But the one on the left has added the behavior of sharing your credit card info with criminals. That's a decorator. Everything looks the same from the outside but new behavior has been added.

Decorators are used when you want to add new behavior without upsetting the rest of the system. The idea is to slip them in unnoticed. It's very powerful. Please don't use it for evil.

_{See also: man in the middle attack}

No. There is no call for an AbstractDecorator. Decorators typically use composition and delegation anyway.

If you're a fan of UML these diagrams might help.

See? No abstract decorator. Component might be abstract but it has no idea the decorator exists. The Decorator both implements the Component interface and accepts a Component. That way it can pretend to be one and pass on what it's told to do to the Component it holds. Why? So it doesn't have to do that work itself. The Decorator can pretend to be both the Component and the Client while making them still do their work. This way all it has to do is add whatever behavior it was created to add.

But let's try an example from the real world.

You're looking at two gas pump credit card readers. Except the one on the left has a skimmer attached. Use either one and you can fuel your car. But the one on the left has added the behavior of sharing your credit card info with criminals. That's a decorator. Everything looks the same from the outside but new behavior has been added.

Decorators are used when you want to add new behavior without upsetting the rest of the system. The idea is to slip them in unnoticed. It's very powerful. Please don't use it for evil.

_{See also: man in the middle attack}

No. There is no call for an AbstractDecorator. Decorators typically use composition and delegation anyway.

If you're a fan of UML these diagrams might help.

See? No abstract decorator. Component might be abstract but it has no idea the decorator exists. The Decorator both implements the Component interface and accepts a Component. That way it can pretend to be one and pass on what it's told to do to the Component it holds. Why? So it doesn't have to do that work itself. It can pretend to be both the Component and the Client without having to do any of their work itself. This way all it has to do is add whatever behavior it was created to add.

But let's try an example from the real world.

You're looking at a gas pump credit card reader. Except the one on the left has a skimmer attached. Use either one and you can get gas. But the one on the left has added the behavior of sharing your credit card info with criminals. That's a decorator. Everything looks the same from the outside but new behavior has been added.

Decorators are used when you want to add new behavior without upsetting the rest of the system. The idea is to slip them in unnoticed. It's very powerful. Please don't use it for evil.

_{See also: man in the middle attack}

No. There is no call for an AbstractDecorator. Decorators typically use composition and delegation anyway.

If you're a fan of UML these diagrams might help.

See? No abstract decorator. Component might be abstract but it has no idea the decorator exists. The Decorator both implements the Component interface and accepts a Component. That way it can pretend to be one and pass on what it's told to do to the Component it holds. Why? So it doesn't have to do that work itself. The Decorator can pretend to be both the Component and the Client while making them still do their work. This way all it has to do is add whatever behavior it was created to add.

But let's try an example from the real world.

You're looking at two gas pump credit card readers. Except the one on the left has a skimmer attached. Use either one and you can get gas. But the one on the left has added the behavior of sharing your credit card info with criminals. That's a decorator. Everything looks the same from the outside but new behavior has been added.

Decorators are used when you want to add new behavior without upsetting the rest of the system. The idea is to slip them in unnoticed. It's very powerful. Please don't use it for evil.

_{See also: man in the middle attack}

No. There is no call for an AbstractDecorator. Decorators typically use composition and delegation anyway.

If you're a fan of UML these diagrams might help.

See? No abstract decorator. Component might be abstract but it has no idea the decorator exists. The Decorator both implements the Component interface and accepts a Component. That way it can pretend to be one and pass on what it's told to do to the Component it holds. Why? So it doesn't have to do that work itself. That way all it has to do is add whatever behavior it was created to add.

But let's try an example from the real world.

You're looking at a gas pump credit card reader. Except the one on the left has a skimmer attached. Use either one and you can get gas. But the one on the left has added the behavior of sharing your credit card info with criminals. That's a decorator. Everything looks the same from the outside but new behavior has been added.

Decorators are used when you want to add new behavior without upsetting the rest of the system. The idea is to slip them in unnoticed. It's very powerful. Please don't use it for evil.

_{See also: man in the middle attack}

No. There is no call for an AbstractDecorator. Decorators typically use composition and delegation anyway.

If you're a fan of UML these diagrams might help.

See? No abstract decorator. Component might be abstract but it has no idea the decorator exists. The Decorator both implements the Component interface and accepts a Component. That way it can pretend to be one and pass on what it's told to do to the Component it holds. Why? So it doesn't have to do that work itself. It can pretend to be both the Component and the Client without having to do any of their work itself. This way all it has to do is add whatever behavior it was created to add.

But let's try an example from the real world.

You're looking at a gas pump credit card reader. Except the one on the left has a skimmer attached. Use either one and you can get gas. But the one on the left has added the behavior of sharing your credit card info with criminals. That's a decorator. Everything looks the same from the outside but new behavior has been added.

Decorators are used when you want to add new behavior without upsetting the rest of the system. The idea is to slip them in unnoticed. It's very powerful. Please don't use it for evil.

_{See also: man in the middle attack}