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:
Markus
parent
0989c9b498
commit
1bef44c4e8
87
README.md
87
README.md
@ -4,25 +4,12 @@
|
||||
|
||||
# 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://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">
|
||||
<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)
|
||||
# Introduction {#intro}
|
||||
|
||||
Design patterns are formalized best practices that the programmer can use to
|
||||
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.
|
||||
|
||||
|
||||
# <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).
|
||||
|
||||
|
||||
# <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)
|
||||
# Credits {#credits}
|
||||
|
||||
* [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)
|
||||
@ -114,6 +41,6 @@ Flyweight.
|
||||
* [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.
|
||||
|
||||
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