sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: java-design-patterns
Issue: Service Adapter pattern
Labels: epic: pattern,type: feature

### Description:
The Service Adapter design pattern aims to provide a bridge between different interfaces, enabling them to work together seamlessly. This pattern involves creating an adapter class that translates one interface for a class into an interface compatible with another class. The key elements of the pattern include:

1. **Client:** The class that requires the target interface.
2. **Target Interface:** The interface needed by the client.
3. **Service Interface:** The existing interface provided by the service.
4. **Adapter:** The class that implements the target interface and translates the requests from the client into calls to the service interface.

This pattern is particularly useful in scenarios where there is a need to integrate with third-party services or legacy systems with incompatible interfaces.

### References:
- [J2EE Design Patterns](https://books.google.fi/books?id=x-7_W0P9KGsC&printsec=frontcover&hl=fi&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

Acceptance Criteria:
1. An adapter class that implements the target interface and translates client requests to the service interface.
2. Unit tests demonstrating the correct functionality of the adapter, ensuring it properly translates and forwards requests.
3. Comprehensive documentation explaining the implemented design pattern, including class diagrams and usage examples.
Repository: java-design-patterns
Issue: Transactional Context pattern
Labels: epic: pattern,type: feature

### Description
Implement the Transactional Context design pattern which ensures that a set of operations are executed within a transaction context, maintaining atomicity, consistency, isolation, and durability (ACID properties). This pattern is essential for managing transactions in complex systems, providing a mechanism to rollback in case of failures, and ensuring that data remains consistent.

Main elements of the pattern include:
- **Transaction**: Represents the transaction boundary, containing operations to commit or rollback changes.
- **Transactional Context**: Maintains the state of the transaction, coordinating the operations and ensuring that they adhere to ACID properties.
- **Transaction Manager**: Manages the lifecycle of transactions, including beginning, committing, and rolling back transactions.
- **Operations**: The individual operations that need to be executed within the transaction context.

### References
- [Java Design Patterns Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)
- [Transactional Context Design Pattern](https://books.google.fi/books?id=x-7_W0P9KGsC&printsec=frontcover&hl=fi&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false)

### Acceptance Criteria
1. Implement classes for Transaction, Transactional Context, Transaction Manager, and Operations as described in the pattern.
2. Ensure that the implementation adheres to the ACID properties.
3. Provide unit tests demonstrating the correct behavior of the transactional context, including scenarios for commit and rollback.
Repository: java-design-patterns
Issue: Lock Manager pattern
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The Lock Manager design pattern is a concurrency control mechanism used to manage access to shared resources in a multi-threaded environment. This pattern ensures that multiple processes or threads do not simultaneously access a shared resource in a way that causes conflicts. The key elements of the Lock Manager design pattern include:

1. **Lock Management:** Centralized control for acquiring and releasing locks on resources.
2. **Lock Types:** Different types of locks, such as read and write locks, to manage varying levels of access control.
3. **Deadlock Detection and Resolution:** Mechanisms to detect and handle deadlocks.
4. **Lock Granularity:** Ability to define locks at different levels of granularity, such as fine-grained or coarse-grained locks.

**References:**
- [Lock Manager Design Pattern - Google Books](https://books.google.fi/books?id=x-7_W0P9KGsC&printsec=frontcover&hl=fi&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

**Acceptance Criteria:**
1. Implement a Lock Manager class that supports acquiring and releasing locks with read and write permissions.
2. Integrate deadlock detection and resolution within the Lock Manager.
3. Provide unit tests demonstrating the correct functionality of the Lock Manager, including scenarios for deadlock detection and handling.
Repository: go
Issue: crypto/x509: check the Key Usage extension
Labels: NeedsFix

We currently ignore the Key Usage extension because some old roots had gotten it wrong. Things probably improved by now and we can take a stab at following the spec again. AFAIK other verifiers do check them.
Repository: java-design-patterns
Issue: Coarse-Grained Lock pattern
Labels: epic: pattern,type: feature


## Description
The Coarse-Grained Lock design pattern is a concurrency control strategy where a single lock is used to protect a large portion of code or multiple related resources. This approach simplifies lock management by reducing the number of locks needed and minimizing the potential for deadlocks. However, it can reduce concurrency as the coarse-grained lock may force threads to wait even when they could safely proceed.

### Main Elements of the Pattern:
- **Single Lock Mechanism**: One lock protects a large code segment or multiple resources.
- **Simplicity**: Easier to implement and manage compared to fine-grained locks.
- **Reduced Concurrency**: May lead to lower parallelism as threads may be unnecessarily blocked.

### Implementation Steps:
1. Identify the critical section or related resources that require protection.
2. Implement a single lock to guard the entire critical section or group of resources.
3. Ensure that the lock is acquired at the beginning and released at the end of the critical section.

## References
- [Coarse-Grained Lock](https://martinfowler.com/eaaCatalog/coarseGrainedLock.html)
- [Java Design Patterns - Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)
- [Youtube](https://www.youtube.com/watch?v=-35OPiQwd8k)

## Acceptance Criteria
1. Implement a Coarse-Grained Lock in a chosen example within the project.
2. Ensure the implementation follows the contribution guidelines provided in the project repository.
3. Include comprehensive unit tests demonstrating the effectiveness and correctness of the Coarse-Grained Lock implementation.
Repository: java-design-patterns
Issue: Database Session State pattern
Labels: epic: pattern,type: feature

### Description:
The Database Session State design pattern is used to manage user session data by storing it in a relational database. This pattern is particularly useful for maintaining session state across multiple servers in a web farm or distributed system, ensuring consistency and reliability.

### Main Elements of the Pattern:
- **Session Data Storage**: Store user session data in a relational database.
- **Session Identifier**: Use a unique session identifier to fetch and update session data.
- **Database Operations**: Implement CRUD operations to manage session data.
- **Session Expiry**: Handle session expiration and cleanup of stale data.
- **Concurrency Handling**: Ensure thread-safe operations and handle concurrent access to session data.

### References:
1. [Martin Fowler - Database Session State](https://martinfowler.com/eaaCatalog/databaseSessionState.html)
2. [YouTube Video on Database Session State](https://www.youtube.com/watch?v=nXBNY7GK--A)
3. [Java Design Patterns - Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

### Acceptance Criteria:
1. Implement a robust solution for storing and retrieving session data from a relational database.
2. Ensure proper handling of session identifiers, session expiration, and cleanup mechanisms.
3. Provide comprehensive documentation and examples demonstrating the usage of the Database Session State pattern in the project.
Repository: java-design-patterns
Issue: Dependent Mapping pattern
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The Dependent Mapping design pattern is used to handle situations where the mapping of one object depends on the mapping of another object. This pattern is particularly useful in scenarios where there are complex relationships between objects and their corresponding database tables. It ensures that dependent objects are mapped correctly and consistently, maintaining the integrity of the data and the relationships between the objects.

Key elements of the Dependent Mapping design pattern include:

1. **Dependent Mapper:** This component is responsible for mapping the dependent objects. It coordinates with the main mapper to ensure that dependent objects are correctly mapped and persisted.
2. **Main Mapper:** The primary mapper that interacts with the database. It delegates the mapping of dependent objects to the dependent mapper.
3. **Relationship Handling:** Proper handling of relationships between the main object and its dependent objects to ensure data integrity and consistency.
4. **Transaction Management:** Ensuring that operations involving dependent objects are part of the same transaction to maintain atomicity.

**References:**
- [Martin Fowler's Dependent Mapping](https://martinfowler.com/eaaCatalog/dependentMapping.html)
- [Source Code Examples on Dependent Mapping Pattern](https://www.sourcecodeexamples.net/2018/05/dependent-mapping-pattern.html)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

**Acceptance Criteria:**
1. Implement the Dependent Mapper and Main Mapper classes that demonstrate the mapping and persistence of dependent objects.
2. Ensure that the relationship between the main object and dependent objects is correctly handled, with appropriate unit tests to verify the integrity and consistency of the data.
3. Include comprehensive documentation and examples within the codebase to illustrate the usage and benefits of the Dependent Mapping design pattern.
Repository: vscode
Issue: Hover widget should restrict height when it's too large
Labels: bug,help wanted,workbench-hover

Context: https://github.com/microsoft/vscode/issues/97496#issuecomment-652651297

![image](https://user-images.githubusercontent.com/2193314/86819678-d7d73f00-c03c-11ea-976e-8d47c4a95a3e.png)
Repository: java-design-patterns
Issue: Foreign Key Mapping pattern
Labels: epic: pattern,type: feature

**Description:**
The Foreign Key Mapping design pattern is used to maintain relationships between tables in a relational database by using foreign keys. This pattern helps in establishing and enforcing referential integrity between related entities. The implementation of this pattern typically involves:

1. Adding foreign key columns in the child table that reference primary keys in the parent table.
2. Ensuring the foreign key constraints are properly defined and maintained.
3. Managing the relationships and ensuring the consistency of data through CRUD operations.

This pattern is essential for ensuring data integrity and facilitating efficient data retrieval in relational database systems.

**References:**
- [Martin Fowler: Foreign Key Mapping](https://martinfowler.com/eaaCatalog/foreignKeyMapping.html)
- [Source Code Examples: Foreign Key Mapping Pattern](https://www.sourcecodeexamples.net/2018/05/foreign-key-mapping-pattern.html)

**Acceptance Criteria:**
1. A new implementation of the Foreign Key Mapping pattern is added to the project, including appropriate classes and database schema.
2. Unit tests are written to cover all CRUD operations, ensuring that referential integrity is maintained.
3. Documentation is updated to explain the Foreign Key Mapping pattern, including code examples and usage guidelines.
Repository: java-design-patterns
Issue: Identity Field pattern
Labels: epic: pattern,type: feature

### Description

The Identity Field design pattern ensures that each object in a system has a unique identifier, which can be used to track the object independently of its database representation. This pattern is particularly useful in systems where objects need to be reconstituted from a persistent storage medium, ensuring that each object retains its unique identity across different sessions and operations.

**Main Elements of the Pattern:**

1. **Unique Identifier:** Each object is assigned a unique identifier, typically a primary key in the database.
2. **Field Mapping:** The identifier field in the object corresponds to a unique column in the database table.
3. **Object Persistence:** Ensures that the unique identifier is consistently used when saving and retrieving objects from the database.

### References

- [Martin Fowler's Identity Field](https://martinfowler.com/eaaCatalog/identityField.html)
- [Source Code Examples - Identity Field Pattern](https://www.sourcecodeexamples.net/2018/05/identity-field-pattern.html)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

### Acceptance Criteria

1. **Unique Identifier Implementation:** Each domain object must have a unique identifier field that maps to the primary key in the database.
2. **Persistence Mechanism:** Implement a mechanism to ensure that objects are saved and retrieved using their unique identifiers, maintaining consistent identity across sessions.
3. **Unit Tests:** Provide comprehensive unit tests to validate the correct assignment, persistence, and retrieval of the unique identifiers for domain objects.
Repository: java-design-patterns
Issue: Implicit Lock pattern
Labels: epic: pattern,type: feature

## Description
The Implicit Lock design pattern ensures that only one thread can execute a particular section of code at a time without requiring explicit lock management by the developer. This is particularly useful in environments where multiple threads need to interact with shared resources, preventing data corruption and ensuring consistency. The pattern leverages synchronized methods or blocks to manage concurrent access automatically, simplifying the code and reducing the likelihood of concurrency-related bugs.

### Main Elements:
1. **Synchronization**: Use of synchronized methods or blocks to control access to critical sections of code.
2. **Automatic Lock Management**: The pattern abstracts lock management away from the developer, reducing the risk of errors.
3. **Concurrency Control**: Ensures that only one thread can execute the synchronized section at a time, preventing race conditions.

### References:
- [Martin Fowler's Catalog](https://martinfowler.com/eaaCatalog/implicitLock.html)
- [YouTube Explanation](https://www.youtube.com/watch?v=kDck7QuFzzg)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

### Acceptance Criteria:
1. Implement the Implicit Lock design pattern using synchronized methods or blocks in a new module.
2. Ensure thorough unit tests are created to validate the concurrency control and proper functioning of the pattern.
3. Update documentation to include an explanation of the Implicit Lock pattern, how it is implemented, and example use cases.
Repository: java-design-patterns
Issue: Layer Supertype pattern
Labels: epic: pattern,type: feature

### Description:
The Layer Supertype design pattern is used to provide a common base class for all objects in a particular layer. This pattern simplifies code maintenance and enforces consistency across similar objects. By implementing a layer supertype, we can centralize common behaviors and properties, reduce code duplication, and facilitate easier modifications and extensions in the future.

### Main elements of the pattern:
1. **Layer Supertype**: A common abstract base class or interface that provides shared methods and properties for all classes in the same layer.
2. **Inheritance**: Concrete classes inherit from the layer supertype to gain common functionality.
3. **Separation of Concerns**: This pattern helps in maintaining a clear separation between different layers of the application, making the code more modular and easier to manage.

### References:
- [Martin Fowler: Layer Supertype](https://martinfowler.com/eaaCatalog/layerSupertype.html)
- [Prashant Brall: Layer Supertype Pattern](https://prashantbrall.wordpress.com/2011/10/25/layer-supertype-pattern/)

### Acceptance Criteria:
1. Create an abstract base class or interface for the chosen layer (e.g., Service Layer, DAO Layer) that includes common properties and methods.
2. Refactor existing classes in the chosen layer to inherit from the new layer supertype, ensuring they implement or utilize the common functionality.
3. Update documentation and examples to demonstrate the use and benefits of the Layer Supertype pattern in the project.
Repository: java-design-patterns
Issue: Pessimistic Offline Lock pattern
Labels: epic: pattern,type: feature

### Description
The Pessimistic Offline Lock design pattern ensures that only one process can access a particular resource at a time, preventing concurrent modifications and ensuring data consistency. This pattern is particularly useful in distributed systems where multiple processes might attempt to modify the same data. By locking resources before making changes, this pattern avoids conflicts and maintains data integrity.

Main elements of the pattern:
- **Lock Management**: Implement a mechanism to acquire and release locks on resources.
- **Transaction Handling**: Ensure that the locks are managed within the scope of transactions to avoid deadlocks and ensure that resources are properly released.
- **Conflict Resolution**: Define strategies to handle situations where a lock cannot be acquired immediately, such as retry mechanisms or user notifications.

### References
- [Pessimistic Offline Lock - Martin Fowler](https://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html)
- [Patterns of Enterprise Application Architecture - Page 303](https://books.google.fi/books?id=vqTfNFDzzdIC&pg=PA303#v=onepage&q&f=false)
- [Java Design Patterns - Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

### Acceptance Criteria
1. Implement a lock management system that allows resources to be locked and unlocked by processes.
2. Ensure that the lock management is integrated with transaction handling to maintain data consistency and avoid deadlocks.
3. Document the implemented pattern with code examples and usage instructions in accordance with the project's contribution guidelines.
Repository: java-design-patterns
Issue: Query Object pattern
Labels: epic: pattern,type: feature

### Description:
The Query Object design pattern encapsulates database queries as objects, allowing for the creation and reuse of complex queries in a more readable and maintainable manner. This pattern separates query construction from execution, promoting single responsibility and enhancing code maintainability. It is particularly useful in systems where queries are complex and frequently changing.

### Main Elements:
1. **Query Object**: Encapsulates the query logic. It contains methods to build and customize the query.
2. **Execution Method**: A method to execute the query built by the Query Object.
3. **Criteria Handling**: Mechanisms to add, remove, and combine query criteria dynamically.
4. **Reusability**: Queries can be reused across different parts of the application.

### References:
- [Martin Fowler's Query Object](https://martinfowler.com/eaaCatalog/queryObject.html)
- [Patterns of Enterprise Application Architecture by Martin Fowler (page 303)](https://books.google.fi/books?id=vqTfNFDzzdIC&pg=PA303#v=onepage&q&f=false)
- [Hojjat's Blog on Query Object Pattern](https://www.hojjatk.com/2018/08/query-object-pattern.html)

### Acceptance Criteria:
1. Implement a basic Query Object that can construct and execute simple queries.
2. Ensure the Query Object can handle dynamic criteria additions, removals, and combinations.
3. Provide examples and documentation demonstrating the usage and benefits of the Query Object design pattern.
Repository: java-design-patterns
Issue: Record Set pattern
Labels: epic: pattern,type: feature

### Description:
Implement the Record Set design pattern to facilitate operations on a collection of records, akin to a database result set. This pattern allows for easy manipulation, retrieval, and iteration of records within a software system. The Record Set pattern is particularly useful for applications that require interaction with a large volume of records or need to provide an abstraction layer for database operations.

### Main Elements of the Pattern:
- **RecordSet Interface**: Defines methods for manipulating and accessing records, such as querying, updating, and iterating over the collection.
- **ConcreteRecordSet**: Implements the RecordSet interface, providing concrete behavior for the methods defined.
- **Record**: Represents a single entry within the RecordSet, encapsulating the data and behaviors specific to a record.
- **Cursor/Iterator**: Facilitates traversal over the records in the RecordSet, allowing clients to navigate through the records efficiently.
- **Operations**: Methods for filtering, sorting, and aggregating records within the RecordSet.

### References:
- [C2 Wiki: Record Set](https://wiki.c2.com/?RecordSet)
- [Google Books: P of EAA](https://books.google.fi/books?id=vqTfNFDzzdIC&pg=PA303#v=onepage&q&f=false)
- [Java Design Patterns Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

Acceptance Criteria:
1. Implement a RecordSet interface with methods for common operations such as querying, updating, and iterating records.
2. Create a ConcreteRecordSet class that provides the implementation for the RecordSet interface.
3. Include unit tests to validate the functionality of the RecordSet implementation, ensuring that all methods behave as expected.
Repository: java-design-patterns
Issue: Remote Facade pattern
Labels: epic: pattern,type: feature

### Description:
The Remote Facade design pattern is an architectural pattern used to provide a coarse-grained interface to a set of fine-grained objects in a distributed system. This pattern helps to reduce the number of remote calls, thus improving performance and encapsulating the complexities of interactions between remote objects. 

Key elements of the Remote Facade design pattern include:
- **Facade Interface**: A high-level interface that aggregates multiple operations into a single call, minimizing the number of remote calls required.
- **Service Layer**: A layer where the facade resides, providing a simplified interface to the underlying subsystem.
- **DTO (Data Transfer Object)**: Objects that carry data between processes to reduce the number of method calls.
- **Remote Communication**: Mechanisms like RMI, web services, or other remote communication protocols to interact with remote objects.

### References:
1. [Martin Fowler's Remote Facade](https://martinfowler.com/eaaCatalog/remoteFacade.html)
2. [StackOverflow: Remote Facade Pattern vs. Facade Pattern](https://stackoverflow.com/questions/20527419/remote-facade-pattern-vs-facade-pattern)
3. [YouTube: Remote Facade Pattern](https://www.youtube.com/watch?v=fBSiUo_cVDQ)
4. [Patterns of Enterprise Application Architecture by Martin Fowler (Google Books)](https://books.google.fi/books?id=vqTfNFDzzdIC&pg=PA303#v=onepage&q&f=false)

### Acceptance Criteria:
1. Implement a Remote Facade that provides a simplified interface for a set of operations on a remote subsystem.
2. Ensure the facade uses Data Transfer Objects (DTOs) to encapsulate data and reduce the number of remote method calls.
3. Document the Remote Facade implementation with appropriate usage examples and ensure it adheres to the project's contribution guidelines. 

Link to project contribution guidelines: [Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)