mirror of
https://github.com/tiennm99/java-design-patterns.git
synced 2026-05-14 14:58:39 +00:00
docs: update collecting parameter
This commit is contained in:
@@ -4,6 +4,8 @@ category: Behavioral
|
||||
language: en
|
||||
tag:
|
||||
- Accumulation
|
||||
- Data processing
|
||||
- Data transfer
|
||||
- Generic
|
||||
---
|
||||
|
||||
@@ -18,56 +20,43 @@ Aims to simplify methods that collect information by passing a single collection
|
||||
|
||||
## Explanation
|
||||
|
||||
### Real-world example
|
||||
Real-world example
|
||||
|
||||
Within a large corporate building, there exists a global printer queue that is a collection of all the printing jobs that are currently pending. Various floors contain different models of printers, each having a different printing policy. We must construct a program that can continually add appropriate printing jobs to a collection, which is called the *collecting parameter*.
|
||||
> Imagine a scenario in a restaurant where a waiter needs to take an order from a customer. Instead of noting down each item separately (e.g., appetizer, main course, dessert, drink), the waiter uses an order form that collects all the items into a single document. This order form simplifies the communication between the waiter and the kitchen staff by aggregating all the details into one place. Similarly, in software, the Collecting Parameter pattern aggregates multiple parameters into a single object, streamlining method calls and improving code readability and maintainability.
|
||||
|
||||
### In plain words
|
||||
In plain words
|
||||
|
||||
Instead of having one giant method that contains numerous policies for collecting information into a variable, we can create numerous smaller functions that each take parameter, and append new information. We can pass the parameter to all of these smaller functions and by the end, we will have what we wanted originally. This time, the code is cleaner and easier to understand. Because the larger function has been broken down, the code is also easier to modify as changes are localised to the smaller functions.
|
||||
> The Collecting Parameter pattern simplifies method calls by encapsulating multiple parameters into a single object.
|
||||
|
||||
### Wikipedia says
|
||||
Wikipedia says
|
||||
|
||||
In the Collecting Parameter idiom a collection (list, map, etc.) is passed repeatedly as a parameter to a method which adds items to the collection.
|
||||
> In the Collecting Parameter idiom a collection (list, map, etc.) is passed repeatedly as a parameter to a method which adds items to the collection.
|
||||
|
||||
### Programmatic example
|
||||
**Programmatic Example**
|
||||
|
||||
Within a large corporate building, there exists a global printer queue that is a collection of all the printing jobs that are currently pending. Various floors contain different models of printers, each having a different printing policy. We must construct a program that can continually add appropriate printing jobs to a collection, which is called the collecting parameter.
|
||||
|
||||
Coding our example from above, we may use the collection `result` as a collecting parameter. The following restrictions are implemented:
|
||||
|
||||
- If an A4 paper is coloured, it must also be single-sided. All other non-coloured papers are accepted
|
||||
- A3 papers must be non-coloured and single-sided
|
||||
- A2 papers must be single-page, single-sided, and non-coloured
|
||||
* If an A4 paper is coloured, it must also be single-sided. All other non-coloured papers are accepted
|
||||
* A3 papers must be non-coloured and single-sided
|
||||
* A2 papers must be single-page, single-sided, and non-coloured
|
||||
|
||||
```java
|
||||
package com.iluwatar.collectingparameter;
|
||||
|
||||
import java.util.LinkedList;
|
||||
import java.util.Queue;
|
||||
|
||||
public class App {
|
||||
|
||||
static PrinterQueue printerQueue = PrinterQueue.getInstance();
|
||||
|
||||
/**
|
||||
* Program entry point.
|
||||
*
|
||||
* @param args command line args
|
||||
*/
|
||||
public static void main(String[] args) {
|
||||
/*
|
||||
Initialising the printer queue with jobs
|
||||
*/
|
||||
// Initialising the printer queue with jobs
|
||||
printerQueue.addPrinterItem(new PrinterItem(PaperSizes.A4, 5, false, false));
|
||||
printerQueue.addPrinterItem(new PrinterItem(PaperSizes.A3, 2, false, false));
|
||||
printerQueue.addPrinterItem(new PrinterItem(PaperSizes.A2, 5, false, false));
|
||||
|
||||
/*
|
||||
This variable is the collecting parameter.
|
||||
*/
|
||||
// This variable is the collecting parameter.
|
||||
var result = new LinkedList<PrinterItem>();
|
||||
|
||||
/*
|
||||
* Using numerous sub-methods to collaboratively add information to the result collecting parameter
|
||||
*/
|
||||
// Using numerous sub-methods to collaboratively add information to the result collecting parameter
|
||||
addA4Papers(result);
|
||||
addA3Papers(result);
|
||||
addA2Papers(result);
|
||||
@@ -79,6 +68,7 @@ We use the `addA4Paper`, `addA3Paper`, and `addA2Paper` methods to populate the
|
||||
|
||||
```java
|
||||
public class App {
|
||||
|
||||
static PrinterQueue printerQueue = PrinterQueue.getInstance();
|
||||
|
||||
/**
|
||||
@@ -164,56 +154,46 @@ which is what we expected.
|
||||
|
||||
## Class diagram
|
||||
|
||||

|
||||

|
||||
|
||||
## Applicability
|
||||
|
||||
Use the Collecting Parameter design pattern when
|
||||
|
||||
- When multiple methods produce a collection of results and you want to aggregate these results in a unified manner.
|
||||
- In scenarios where reducing the number of collections created by methods can improve memory efficiency and performance.
|
||||
- When you're refactoring large methods that perform multiple tasks, including the collection of results from various operations.
|
||||
* Use when a method needs to accept a large number of parameters, making the method signature unwieldy.
|
||||
* Use when the same group of parameters is passed to multiple methods, reducing redundancy and potential errors.
|
||||
* Use to improve the readability and maintainability of the code.
|
||||
|
||||
## Tutorials
|
||||
|
||||
Tutorials for this method are found in:
|
||||
|
||||
- [Refactoring To Patterns](http://www.tarrani.net/RefactoringToPatterns.pdf) by Joshua Kerivsky
|
||||
- [Smalltalk Best Practice Patterns](https://ptgmedia.pearsoncmg.com/images/9780134769042/samplepages/013476904X.pdf) by Kent Beck
|
||||
* [Refactoring To Patterns (Joshua Kerivsky)](http://www.tarrani.net/RefactoringToPatterns.pdf)
|
||||
* [Smalltalk Best Practice Patterns (Kent Beck)](https://ptgmedia.pearsoncmg.com/images/9780134769042/samplepages/013476904X.pdf)
|
||||
|
||||
## Known uses
|
||||
|
||||
Joshua Kerivsky gives a real-world example in his book 'Refactoring to Patterns'. He gives an example of using the Collecting Parameter Design Pattern to create a `toString()` method for an XML tree. Without using this design pattern, this would require a bulky function with conditionals and concatenation that would worsen code readability. Such a method can be broken down into smaller methods, each appending their own set of information to the collecting parameter. See this in [Refactoring To Patterns](http://www.tarrani.net/RefactoringToPatterns.pdf).
|
||||
|
||||
Other examples include:
|
||||
|
||||
- Aggregating error messages or validation failures across a complex validation process.
|
||||
- Collecting elements or information while traversing a complex data structure.
|
||||
- Refactoring complex reporting functionalities where various parts of a report are generated by different methods.
|
||||
* Use when a method needs to accept a large number of parameters, making the method signature unwieldy.
|
||||
* Use when the same group of parameters is passed to multiple methods, reducing redundancy and potential errors.
|
||||
* Use to improve the readability and maintainability of the code.
|
||||
|
||||
## Consequences
|
||||
|
||||
Benefits:
|
||||
|
||||
- Reduces code duplication by centralizing collection handling in a single place.
|
||||
- Enhances clarity and maintainability by making it explicit where and how results are collected.
|
||||
- Improves performance by minimizing the creation and management of multiple collection objects.
|
||||
* Improves code readability by reducing the number of parameters in method signatures.
|
||||
* Facilitates the reuse of parameter sets across different methods.
|
||||
* Enhances maintainability by centralizing the parameter structure.
|
||||
|
||||
Trade-offs:
|
||||
|
||||
- Increases coupling between the caller and the methods being called since they must agree on the collection to use.
|
||||
- May introduce side effects in methods if not carefully managed, as methods are no longer self-contained in their result handling.
|
||||
* Introduces an additional class, which may increase complexity if not managed properly.
|
||||
* Can lead to over-generalization if the parameter object becomes too large or unwieldy.
|
||||
|
||||
## Related patterns
|
||||
|
||||
- [Composite](https://java-design-patterns.com/patterns/composite/): Can be used in tandem with Collecting Parameter when dealing with hierarchical structures, allowing results to be collected across a composite structure.
|
||||
- [Visitor](https://java-design-patterns.com/patterns/visitor/): Often used together, where Visitor handles traversal and operations on a structure, and Collecting Parameter accumulates the results.
|
||||
- [Command](https://java-design-patterns.com/patterns/command/): Commands may utilize Collecting Parameter to aggregate results from multiple operations executed by the command objects.
|
||||
* [Command](https://java-design-patterns.com/patterns/command/): Commands may utilize Collecting Parameter to aggregate results from multiple operations executed by the command objects.
|
||||
* [Composite](https://java-design-patterns.com/patterns/composite/): Can be used in tandem with Collecting Parameter when dealing with hierarchical structures, allowing results to be collected across a composite structure.
|
||||
* [Visitor](https://java-design-patterns.com/patterns/visitor/): Often used together, where Visitor handles traversal and operations on a structure, and Collecting Parameter accumulates the results.
|
||||
|
||||
## Credits
|
||||
|
||||
- [Refactoring To Patterns](http://www.tarrani.net/RefactoringToPatterns.pdf) by Joshua Kerivsky
|
||||
- [Smalltalk Best Practice Patterns](https://ptgmedia.pearsoncmg.com/images/9780134769042/samplepages/013476904X.pdf) by Kent Beck
|
||||
- [Wiki](https://wiki.c2.com/?CollectingParameter)
|
||||
- [Refactoring: Improving the Design of Existing Code](https://amzn.to/3TVEgaB)
|
||||
- [Clean Code: A Handbook of Agile Software Craftsmanship](https://amzn.to/4aApLP0)
|
||||
* [Clean Code: A Handbook of Agile Software Craftsmanship](https://amzn.to/4aApLP0)
|
||||
* [Refactoring: Improving the Design of Existing Code](https://amzn.to/3TVEgaB)
|
||||
* [Collecting Parameter (WikiWikiWeb)](https://wiki.c2.com/?CollectingParameter)
|
||||
|
||||
Reference in New Issue
Block a user