fix #237
- Removed Self-Links and instead used another way of making custom id's - Removed TOC - Removed Back to top arrows - Made FAQ an extra page
This commit is contained in:
parent
0989c9b498
commit
1bef44c4e8
87
README.md
87
README.md
@ -4,25 +4,12 @@
|
|||||||
|
|
||||||
# Design pattern samples in Java
|
# Design pattern samples in Java
|
||||||
|
|
||||||
|
[](https://travis-ci.org/iluwatar/java-design-patterns)
|
||||||
|
[](https://coveralls.io/r/iluwatar/java-design-patterns?branch=master)
|
||||||
|
[](https://scan.coverity.com/projects/5634)
|
||||||
[](https://gitter.im/iluwatar/java-design-patterns?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
|
[](https://gitter.im/iluwatar/java-design-patterns?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
|
||||||
|
|
||||||
[](https://travis-ci.org/iluwatar/java-design-patterns) [](https://coveralls.io/r/iluwatar/java-design-patterns?branch=master) <a href="https://scan.coverity.com/projects/5634">
|
# Introduction {#intro}
|
||||||
<img alt="Coverity Scan Build Status"
|
|
||||||
src="https://scan.coverity.com/projects/5634/badge.svg"/>
|
|
||||||
</a>
|
|
||||||
|
|
||||||
|
|
||||||
<a name="top"/>
|
|
||||||
|
|
||||||
# <a name="toc">Table of Contents</a>
|
|
||||||
- <a href="#introduction">Introduction</a>
|
|
||||||
- <a href="#contribute">How to contribute</a>
|
|
||||||
- <a href="#faq">Frequently Asked Questions</a>
|
|
||||||
- <a href="#credits">Credits</a>
|
|
||||||
- <a href="#license">License</a>
|
|
||||||
|
|
||||||
|
|
||||||
# <a name="introduction">Introduction</a> [↑](#top)
|
|
||||||
|
|
||||||
Design patterns are formalized best practices that the programmer can use to
|
Design patterns are formalized best practices that the programmer can use to
|
||||||
solve common problems when designing an application or system.
|
solve common problems when designing an application or system.
|
||||||
@ -35,71 +22,11 @@ problems, and it also improves code readability for coders and architects who
|
|||||||
are familiar with the patterns.
|
are familiar with the patterns.
|
||||||
|
|
||||||
|
|
||||||
# <a name="contribute">How to contribute</a> [↑](#top)
|
# How to contribute {#contribute}
|
||||||
|
|
||||||
If you are willing to contribute to the project you will find the relevant information in our [developer wiki](https://github.com/iluwatar/java-design-patterns/wiki).
|
If you are willing to contribute to the project you will find the relevant information in our [developer wiki](https://github.com/iluwatar/java-design-patterns/wiki).
|
||||||
|
|
||||||
|
# Credits {#credits}
|
||||||
# <a name="faq">Frequently asked questions</a> [↑](#top)
|
|
||||||
|
|
||||||
**<a id="Q1">Q: What is the difference between State and Strategy patterns?</a>**
|
|
||||||
|
|
||||||
While the implementation is similar they solve different problems. The State
|
|
||||||
pattern deals with what state an object is in - it encapsulates state-dependent
|
|
||||||
behavior.
|
|
||||||
The Strategy pattern deals with how an object performs a certain task - it
|
|
||||||
encapsulates an algorithm.
|
|
||||||
|
|
||||||
**<a id="Q2">Q: What is the difference between Strategy and Template Method patterns?</a>**
|
|
||||||
|
|
||||||
In Template Method the algorithm is chosen at compile time via inheritance.
|
|
||||||
With Strategy pattern the algorithm is chosen at runtime via composition.
|
|
||||||
|
|
||||||
**<a id="Q3">Q: What is the difference between Proxy and Decorator patterns?</a>**
|
|
||||||
|
|
||||||
The difference is the intent of the patterns. While Proxy controls access to
|
|
||||||
the object Decorator is used to add responsibilities to the object.
|
|
||||||
|
|
||||||
**<a id="Q4">Q: What is the difference between Chain of Responsibility and Intercepting Filter patterns?</a>**
|
|
||||||
|
|
||||||
While the implementations look similar there are differences. The Chain of
|
|
||||||
Responsibility forms a chain of request processors and the processors are then
|
|
||||||
executed one by one until the correct processor is found. In Intercepting
|
|
||||||
Filter the chain is constructed from filters and the whole chain is always
|
|
||||||
executed.
|
|
||||||
|
|
||||||
**<a id="Q5">Q: What is the difference between Visitor and Double Dispatch patterns?</a>**
|
|
||||||
|
|
||||||
The Visitor pattern is a means of adding a new operation to existing classes.
|
|
||||||
Double dispatch is a means of dispatching function calls with respect to two
|
|
||||||
polymorphic types, rather than a single polymorphic type, which is what
|
|
||||||
languages like C++ and Java _do not_ support directly.
|
|
||||||
|
|
||||||
**<a id="Q6">Q: What are the differences between Flyweight and Object Pool patterns?</a>**
|
|
||||||
|
|
||||||
They differ in the way they are used.
|
|
||||||
|
|
||||||
Pooled objects can simultaneously be used by a single "client" only. For that,
|
|
||||||
a pooled object must be checked out from the pool, then it can be used by a
|
|
||||||
client, and then the client must return the object back to the pool. Multiple
|
|
||||||
instances of identical objects may exist, up to the maximal capacity of the
|
|
||||||
pool.
|
|
||||||
|
|
||||||
In contrast, a Flyweight object is singleton, and it can be used simultaneously
|
|
||||||
by multiple clients.
|
|
||||||
|
|
||||||
As for concurrent access, pooled objects can be mutable and they usually don't
|
|
||||||
need to be thread safe, as typically, only one thread is going to use a
|
|
||||||
specific instance at the same time. Flyweight must either be immutable (the
|
|
||||||
best option), or implement thread safety.
|
|
||||||
|
|
||||||
As for performance and scalability, pools can become bottlenecks, if all the
|
|
||||||
pooled objects are in use and more clients need them, threads will become
|
|
||||||
blocked waiting for available object from the pool. This is not the case with
|
|
||||||
Flyweight.
|
|
||||||
|
|
||||||
|
|
||||||
# <a name="credits">Credits</a> [↑](#top)
|
|
||||||
|
|
||||||
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
|
||||||
* [Effective Java (2nd Edition)](http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683)
|
* [Effective Java (2nd Edition)](http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683)
|
||||||
@ -114,6 +41,6 @@ Flyweight.
|
|||||||
* [Pattern Oriented Software Architecture Vol I-V](http://www.amazon.com/Pattern-Oriented-Software-Architecture-Volume-Patterns/dp/0471958697)
|
* [Pattern Oriented Software Architecture Vol I-V](http://www.amazon.com/Pattern-Oriented-Software-Architecture-Volume-Patterns/dp/0471958697)
|
||||||
|
|
||||||
|
|
||||||
# <a name="license">License</a> [↑](#top)
|
# License {#license}
|
||||||
|
|
||||||
This project is licensed under the terms of the MIT license.
|
This project is licensed under the terms of the MIT license.
|
||||||
|
63
faq.md
Normal file
63
faq.md
Normal file
@ -0,0 +1,63 @@
|
|||||||
|
---
|
||||||
|
layout: page
|
||||||
|
title: FAQ
|
||||||
|
permalink: /faq/
|
||||||
|
icon: fa-question
|
||||||
|
page-index: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
### Q1: What is the difference between State and Strategy patterns? {#Q1}
|
||||||
|
|
||||||
|
While the implementation is similar they solve different problems. The State
|
||||||
|
pattern deals with what state an object is in - it encapsulates state-dependent
|
||||||
|
behavior.
|
||||||
|
The Strategy pattern deals with how an object performs a certain task - it
|
||||||
|
encapsulates an algorithm.
|
||||||
|
|
||||||
|
### Q2: What is the difference between Strategy and Template Method patterns? {#Q2}
|
||||||
|
|
||||||
|
In Template Method the algorithm is chosen at compile time via inheritance.
|
||||||
|
With Strategy pattern the algorithm is chosen at runtime via composition.
|
||||||
|
|
||||||
|
### Q3: What is the difference between Proxy and Decorator patterns? {#Q3}
|
||||||
|
|
||||||
|
The difference is the intent of the patterns. While Proxy controls access to
|
||||||
|
the object Decorator is used to add responsibilities to the object.
|
||||||
|
|
||||||
|
### Q4: What is the difference between Chain of Responsibility and Intercepting Filter patterns? {#Q4}
|
||||||
|
|
||||||
|
While the implementations look similar there are differences. The Chain of
|
||||||
|
Responsibility forms a chain of request processors and the processors are then
|
||||||
|
executed one by one until the correct processor is found. In Intercepting
|
||||||
|
Filter the chain is constructed from filters and the whole chain is always
|
||||||
|
executed.
|
||||||
|
|
||||||
|
### Q5: What is the difference between Visitor and Double Dispatch patterns? {#Q5}
|
||||||
|
|
||||||
|
The Visitor pattern is a means of adding a new operation to existing classes.
|
||||||
|
Double dispatch is a means of dispatching function calls with respect to two
|
||||||
|
polymorphic types, rather than a single polymorphic type, which is what
|
||||||
|
languages like C++ and Java _do not_ support directly.
|
||||||
|
|
||||||
|
### Q6: What are the differences between Flyweight and Object Pool patterns? {#Q6}
|
||||||
|
|
||||||
|
They differ in the way they are used.
|
||||||
|
|
||||||
|
Pooled objects can simultaneously be used by a single "client" only. For that,
|
||||||
|
a pooled object must be checked out from the pool, then it can be used by a
|
||||||
|
client, and then the client must return the object back to the pool. Multiple
|
||||||
|
instances of identical objects may exist, up to the maximal capacity of the
|
||||||
|
pool.
|
||||||
|
|
||||||
|
In contrast, a Flyweight object is singleton, and it can be used simultaneously
|
||||||
|
by multiple clients.
|
||||||
|
|
||||||
|
As for concurrent access, pooled objects can be mutable and they usually don't
|
||||||
|
need to be thread safe, as typically, only one thread is going to use a
|
||||||
|
specific instance at the same time. Flyweight must either be immutable (the
|
||||||
|
best option), or implement thread safety.
|
||||||
|
|
||||||
|
As for performance and scalability, pools can become bottlenecks, if all the
|
||||||
|
pooled objects are in use and more clients need them, threads will become
|
||||||
|
blocked waiting for available object from the pool. This is not the case with
|
||||||
|
Flyweight.
|
Loading…
x
Reference in New Issue
Block a user