added builder pattern

README.md

@@ -83,6 +83,7 @@ If you find yourself in a context with a problem that has a goal that is affecte
 12. Composite
 13. State
 14. Proxy
+15. Builder
 
 * **Strategy Pattern:** The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently of clients that use it.
   * **Example:** [An action game design using Strategy pattern](https://github.com/Devansh-Maurya/Design-Patterns-And-Principles/tree/master/src/strategy/actiongame)
@@ -147,4 +148,9 @@ If you find yourself in a context with a problem that has a goal that is affecte
     8. **Complexity Hiding Proxy: Hides the complexity of and controls access to a complex set of classes.** This is sometimes called the Facade Proxy for obvious reasons. The Complexity Hiding Proxy differs from the Facade Pattern in that the proxy controls access, while the Facade just provides an alternative interface.
     9. **Copy-On-Write Proxy: Controls the copying of an object by deferring the copying of an object until it is required by a client.** This is a variant of the **Virtual Proxy**. Seen in Java's `CopyOnWriteArrayList`.
 
-  Proxy is structurally similar to Decorator, but the two differ in their purpose. The Decorator Pattern adds behavior to an object, while a Proxy controls access. Like any wrapper, proxies will increase the number of classes and objects in your designs.
+  Proxy is structurally similar to Decorator, but the two differ in their purpose. The Decorator Pattern adds behavior to an object, while a Proxy controls access. Like any wrapper, proxies will increase the number of classes and objects in your designs.
+
+* **Builder Pattern: The Builder Pattern helps in construction of complex objects. Typically, you want that an object can only be created by a builder and adheres to some validation, which you can put in the build method.
+  * **Example:** [Building a book](src/builder)
+
+  Proxy is   

builder/Builder.kt

@@ -0,0 +1,39 @@
+package builder
+
+class Book private constructor(
+	val title: String,
+	val author: String,
+	val publisher: String?
+) {
+	data class Builder(
+		var title: String? = null,
+		var author: String? = null,
+		var publisher: String? = null) {
+
+		fun title(title: String) = apply { this.title = title }
+		fun author(author: String) = apply { this.author = author }
+		fun build(): Book {
+			//typically, this part is why you use a builder. you want to asure that the object constructed is valid.
+			if (title != null) {
+				throw IllegalArgumentException("title must not be null")
+			}
+
+			// this is a validation normal data class constructors can't handle
+			if (title.length < 5) {
+				throw IllegalArgumentException("title is too short")
+			}
+			if (author == null) {
+				throw IllegalArgumentException("author must not be null")
+			}
+			return Book(title!!, author!!, publisher)
+		}
+	}
+}
+
+fun main() {
+	// Produces a valid book with title and author
+	val book = Book.Builder()
+		.author("Stephen King")
+		.title("Mr. Mercedes")
+		.build()
+}