Design patterns are the best, formalized practices a programmer can use to solve common problems when designing an application or system.

Design patterns can speed up the development process by providing tested, proven development paradigms.

Reusing design patterns help prevent subtle issues that cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

This site showcases Kotlin Design Patterns. The solutions have been developed by experienced programmers and architects from the open-source community. The patterns can be browsed by their high-level descriptions or by looking at their source code. The source code examples are well commented and can be thought of as programming tutorials on how to implement a specific pattern. We use the most popular battle-proven open-source Java technologies.

Before you dive into the material, you should be familiar with various Software Design Principles.

All designs should be as simple as possible. You should start with KISS, YAGNI, and Do The Simplest Thing That Could Possibly Work principles. Complexity and patterns should only be introduced when they are needed for practical extensibility.

Once you are familiar with these concepts you can start drilling down into the available design patterns by any of the following approaches

• Search for a specific pattern by name. Can't find one? Please report a new pattern here.
• Using tags such as Performance, Gang of Four or Data access.
• Using pattern categories, Creational, Behavioral, and others.

Hopefully, you find the object-oriented solutions presented on this site useful in your architectures and have as much fun learning them as we had while developing them.

You can find all patterns grouped by their category here.

This project is licensed under the terms of the MIT license.

This repository is the Kotlin version of java-design-patterns. It is heavily inspired by the original Java version, and all the credit for the patterns goes to the original authors, except to some adaptations for Kotlin more idiomatic features.