(NEW) Illustrative classes:
- App: simulates a production application
- BusinessOperation<T>: abstraction over any operation that can
potentially fail
- FindCustomer <: BusinessOperation<String>: illustrative
operation that can throw an error
- Retry <: BusinessOperation<T>: transparently implements the
retry mechanism
- Several "business" exceptions:
- BusinessException: top-level
- CustomerNotFoundException: can be ignored
- DatabaseNotAvailableException: fatal error
(NEW) .puml and .png for UML
Trolls should not be re-declared: if I had a troll called Zac, one day I
gave him a weapon.I can not because he now has a weapon called him
Trundle. He is still Zac.
- final fields are marked as final
- removed unnecessary temp variables
- added private constructor for not instantiated static class AccountAggregate
- path of te test file is corrected
Keeping wait() calls with in synchronized block closely to adhere
SonarQube rules.
Avoid nested synchronized block by extracting method.
Added writing and reading time to simulate testing to ensure
1) writers are waiting for globalMutex to be empty
2) readers to confirm there is no writers.
resources (Connection, Statement and resultSet) until the stream is
closed by the consumer. So try-with-resources is not an option as per
sonarqube’s recommendation. But it is still recommended to close
statement and result set. When connection pool used, connection is not
closed when close() called. It is just returned to the pool.
Using //NOSONAR to avoid false blocker issue.
When the system is not capable to play the sound, do not throw
exception, just log it. For example on Linux there are several issues to
play sound and there are no workarounds for that :(
* upstream/master: (67 commits)
Set version for next development iteration
Reached milestone 1.15.0
#539 Checkstyle fix
#539 More Checkstyle fixes
#539 Checkstyle fixes
#497 Add missing puml and license headers
#77 Add missing license header
Work on #190: urm/puml updates * added pumlid where it was missing and possible * removed pumlid where it generated a bad image * regenerated some incorrect puml's * added 'left to right direction' puml prefix to some diagrams to improve the automatic layouting
Removed AvoidStarImport Rule Added JavaDocType Rule
Update App.java
Update App.java
Update after changes from review. Additional improvements.
Pom.xml files fixed.
#66 Balking Pattern
fixed pmd violation
fixed checkstyle violations
diagrams added
comments, tests and description
changed parent POM version #69
apply changes from review #69
...
# Conflicts:
# pom.xml
* added pumlid where it was missing and possible
* removed pumlid where it generated a bad image
* regenerated some incorrect puml's
* added 'left to right direction' puml prefix to some diagrams to improve the automatic layouting
The relationship between decorator and target (in the code example between Troll und SmartTroll) ist not a composition as described in the code comment lines of class App. It's a aggregation. In a composition both instances canncot live without the other one. But the target (Troll) could live without the decorator (Smart Troll). Changed "composition" to "aggregation" in the comment lines. Code lines are unchanged.
Greetings Thomas
* 'master' of https://github.com/iluwatar/java-design-patterns: (27 commits)
Remove use of coveralls-maven-plugin (sonarqube.com covers this)
Add SonarQube.com badge
Fix environment variable
Add Travis instructions for SonarQube.com analysis
Adds more criticism to Singleton pattern.
Event Based Asynchronous pattern: Add missing license header and puml diagram
Changed config to non-interactive
Moved config into a separate dir
Unused import removed.
End process logic clause has been corrected.
Caching pattern: Documentation and diagram
Fixes#437. Adds criticism to Singleton pattern.
Alter JUnit tests to run in lesser time.
Updated version snapshot to 1.14.0
Changes based on review feedback.
Closes#436. Adds criticism to service locator pattern.
Caching pattern: Implementation of Cache-Aside pattern
Caching pattern: Style fix for null check
Caching pattern: Refactor LRU cache to avoid NPE and unnecessary cache lookup
Caching pattern: Refactor shutdown hook to use method reference
...
Add a simple king and queen classes which implement the behaviour of the
royalty interface. Also wrote the object mother of royalty objects which
is final so you can just call the static methods in it to create objects
with a specific state to use them fast in tests. The tests are already
created for testing the behaviour and the type of the objects which are
created by the object mother.
I also created the UML diagrams via object aid and updated the readme.
[](https://gitter.im/iluwatar/java-design-patterns?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
> To create a kingdom we need objects with common theme. Elven kingdom needs an Elven king, Elven castle and Elven army whereas Orcish kingdom needs an Orcish king, Orcish castle and Orcish army. There is a dependency between the objects in the kingdom.
In plain words
> A factory of factories; a factory that groups the individual but related/dependent factories together without specifying their concrete classes.
Wikipedia says
> The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes
**Programmatic Example**
Translating the kingdom example above. First of all we have some interfaces and implementation for the objects in the kingdom
```
public interface Castle {
String getDescription();
}
public interface King {
String getDescription();
}
public interface Army {
String getDescription();
}
// Elven implementations ->
public class ElfCastle implements Castle {
static final String DESCRIPTION = "This is the Elven castle!";
@Override
public String getDescription() {
return DESCRIPTION;
}
}
public class ElfKing implements King {
static final String DESCRIPTION = "This is the Elven king!";
@Override
public String getDescription() {
return DESCRIPTION;
}
}
public class ElfArmy implements Army {
static final String DESCRIPTION = "This is the Elven Army!";
@Override
public String getDescription() {
return DESCRIPTION;
}
}
// Orcish implementations similarly...
```
Then we have the abstraction and implementations for the kingdom factory
```
public interface KingdomFactory {
Castle createCastle();
King createKing();
Army createArmy();
}
public class ElfKingdomFactory implements KingdomFactory {
public Castle createCastle() {
return new ElfCastle();
}
public King createKing() {
return new ElfKing();
}
public Army createArmy() {
return new ElfArmy();
}
}
public class OrcKingdomFactory implements KingdomFactory {
public Castle createCastle() {
return new OrcCastle();
}
public King createKing() {
return new OrcKing();
}
public Army createArmy() {
return new OrcArmy();
}
}
```
Now we have our abstract factory that lets us make family of related objects i.e. Elven kingdom factory creates Elven castle, king and army etc.
```
KingdomFactory factory = new ElfKingdomFactory();
Castle castle = factory.createCastle();
King king = factory.createKing();
Army army = factory.createArmy();
castle.getDescription(); // Output: This is the Elven castle!
king.getDescription(); // Output: This is the Elven king!
army.getDescription(); // Output: This is the Elven Army!
```
Now, we can design a factory for our different kingdom factories. In this example, we created FactoryMaker, responsible for returning an instance of either ElfKingdomFactory or OrcKingdomFactory.
The client can use FactoryMaker to create the desired concrete factory which, in turn, will produce different concrete objects (Army, King, Castle).
In this example, we also used an enum to parameterize which type of kingdom factory the client will ask for.
```
public static class FactoryMaker {
public enum KingdomType {
ELF, ORC
}
public static KingdomFactory makeFactory(KingdomType type) {
switch (type) {
case ELF:
return new ElfKingdomFactory();
case ORC:
return new OrcKingdomFactory();
default:
throw new IllegalArgumentException("KingdomType not supported.");
> "The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes"
<br/>
* In plain words:
* A factory that groups individual but related/dependent factories together without specifying their concrete classes;
* A factory of factories;
---
# Example
* In a factory that creates kingdoms, we need objects with common theme:
* Elven kingdom needs an Elven king, Elven castle and Elven army;
* Orcish kingdom needs an Orcish king, Orcish castle and Orcish army;
<br/>
* There is a dependency between the objects in the kingdom;
---
# Diagram
* Based on the kingdom example, the diagram below showcases the different concrete factories and their concrete products:
.center[]
---
# Diagram
* The class diagram below showcases the factory of factories;
* At runtime, we can define which Kingdom type is needed and pass it as a parameter to define which concrete KingdomFactory to instantiate;
* The concrete factory returned will then be able to produce the related objects of the specified type;
.center[]
---
# Applicability
Use the Abstract Factory pattern when:
* A system should be independent of how its products are created, composed and represented;
* A system should be configured with one of multiple families of products;
* A family of related product objects is designed to be used together, and you need to enforce this constraint;
* You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations;
---
# Applicability
Use the Abstract Factory pattern when:
* The lifetime of the dependency is conceptually shorter than the lifetime of the consumer;
* You need a run-time value to construct a particular dependency;
* You want to decide which product to call from a family at runtime;
* You need to supply one or more parameters only known at run-time before you can resolve a dependency;
---
#Use Cases
* Selecting to call the appropriate implementation of FileSystemAcmeService or DatabaseAcmeService or NetworkAcmeService at runtime;
* Unit test case writing becomes much easier;
---
# Consequences
* Dependency injection in java hides the service class dependencies that can lead to runtime errors that would have been caught at compile time
* [Design Patterns: Elements of Reusable Object-Oriented Software](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
@ -18,7 +18,85 @@ Convert the interface of a class into another interface the clients
expect. Adapter lets classes work together that couldn't otherwise because of
incompatible interfaces.
## Explanation
Real world example
> Consider that you have some pictures in your memory card and you need to transfer them to your computer. In order to transfer them you need some kind of adapter that is compatible with your computer ports so that you can attach memory card to your computer. In this case card reader is an adapter.
> Another example would be the famous power adapter; a three legged plug can't be connected to a two pronged outlet, it needs to use a power adapter that makes it compatible with the two pronged outlet.
> Yet another example would be a translator translating words spoken by one person to another
In plain words
> Adapter pattern lets you wrap an otherwise incompatible object in an adapter to make it compatible with another class.
Wikipedia says
> In software engineering, the adapter pattern is a software design pattern that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.
**Programmatic Example**
Consider a captain that can only use rowing boats and cannot sail at all.
First we have interfaces `RowingBoat` and `FishingBoat`
```
public interface RowingBoat {
void row();
}
public class FishingBoat {
private static final Logger LOGGER = LoggerFactory.getLogger(FishingBoat.class);
public void sail() {
LOGGER.info("The fishing boat is sailing");
}
}
```
And captain expects an implementation of `RowingBoat` interface to be able to move
```
public class Captain implements RowingBoat {
private RowingBoat rowingBoat;
public Captain(RowingBoat rowingBoat) {
this.rowingBoat = rowingBoat;
}
@Override
public void row() {
rowingBoat.row();
}
}
```
Now let's say the pirates are coming and our captain needs to escape but there is only fishing boat available. We need to create an adapter that allows the captain to operate the fishing boat with his rowing boat skills.
```
public class FishingBoatAdapter implements RowingBoat {
private static final Logger LOGGER = LoggerFactory.getLogger(FishingBoatAdapter.class);
private FishingBoat boat;
public FishingBoatAdapter() {
boat = new FishingBoat();
}
@Override
public void row() {
boat.sail();
}
}
```
And now the `Captain` can use the `FishingBoat` to escape the pirates.
```
Captain captain = new Captain(new FishingBoatAdapter());
captain.row();
```
## Applicability
Use the Adapter pattern when
@ -26,10 +104,28 @@ Use the Adapter pattern when
* you want to use an existing class, and its interface does not match the one you need
* you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces
* you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.
* most of the applications using third party libraries use adapters as a middle layer between the application and the 3rd party library to decouple the application from the library. If another library has to be used only an adapter for the new library is required without having to change the application code.
## Consequences:
Class and object adapters have different trade-offs. A class adapter
* adapts Adaptee to Target by committing to a concrete Adaptee class. As a consequence, a class adapter won’t work when we want to adapt a class and all its subclasses.
* let’s Adapter override some of Adaptee’s behavior, since Adapter is a subclass of Adaptee.
* introduces only one object, and no additional pointer indirection is needed to get to the adaptee.
An object adapter
* let’s a single Adapter work with many Adaptees—that is, the Adaptee itself and all of its subclasses (if any). The Adapter can also add functionality to all Adaptees at once.
* makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making Adapter refer to the subclass rather than the Adaptee itself.
@ -141,7 +139,7 @@ public class ThreadAsyncExecutor implements AsyncExecutor {
@Override
publicvoidawait()throwsInterruptedException{
synchronized(lock){
if(!isCompleted()){
while(!isCompleted()){
lock.wait();
}
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
