<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Creational Design Patterns on Abhishek Shukla</title><link>https://abhishekshukla.dev/tags/creational-design-patterns/</link><description>Recent content in Creational Design Patterns on Abhishek Shukla</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 23 Jun 2026 12:00:00 +0530</lastBuildDate><atom:link href="https://abhishekshukla.dev/tags/creational-design-patterns/index.xml" rel="self" type="application/rss+xml"/><item><title>The Singleton Design Pattern in Swift: Why, How, and When NOT to Use It</title><link>https://abhishekshukla.dev/blog/singleton-design-pattern/</link><pubDate>Tue, 23 Jun 2026 05:47:17 +0530</pubDate><guid>https://abhishekshukla.dev/blog/singleton-design-pattern/</guid><description>&lt;p&gt;The &lt;strong&gt;Singleton&lt;/strong&gt; is one of the most well-known—and heavily debated—creational design patterns in software engineering. Apple uses it extensively throughout the iOS SDK (&lt;code&gt;UserDefaults.standard&lt;/code&gt;, &lt;code&gt;URLSession.shared&lt;/code&gt;, &lt;code&gt;NotificationCenter.default&lt;/code&gt;), which often leads developers to believe it should be used everywhere.&lt;/p&gt;
&lt;p&gt;However, while Singletons are incredibly easy to create in Swift, they are equally easy to abuse.&lt;/p&gt;
&lt;p&gt;In this post, we will explore what the Singleton pattern is, why and how to implement it, where it makes sense, and most importantly, where you should avoid it.&lt;/p&gt;</description></item><item><title>The Factory Method Pattern in Swift: Decoupling Object Creation</title><link>https://abhishekshukla.dev/blog/factory-method-design-pattern/</link><pubDate>Tue, 23 Jun 2026 08:28:30 +0530</pubDate><guid>https://abhishekshukla.dev/blog/factory-method-design-pattern/</guid><description>&lt;p&gt;As your application grows, the way you create and manage objects becomes just as important as how those objects behave. If your code is littered with complex initialization logic or massive &lt;code&gt;switch&lt;/code&gt; statements deciding which object to create, you are likely creating tightly coupled, fragile code.&lt;/p&gt;
&lt;p&gt;Enter the &lt;strong&gt;Factory Method&lt;/strong&gt; pattern.&lt;/p&gt;
&lt;p&gt;This creational design pattern provides an interface for creating objects, but delegates the exact type of object being created to a dedicated &amp;ldquo;factory.&amp;rdquo; In modern Swift, this pattern is often implemented using protocols and static methods, keeping our business logic incredibly clean.&lt;/p&gt;</description></item><item><title>The Builder Pattern in Modern Swift: Beyond the Gang of Four</title><link>https://abhishekshukla.dev/blog/builder-design-pattern/</link><pubDate>Tue, 23 Jun 2026 12:00:00 +0530</pubDate><guid>https://abhishekshukla.dev/blog/builder-design-pattern/</guid><description>&lt;p&gt;The Builder Pattern is a creational design pattern designed to separate the construction of a complex object from its representation.&lt;/p&gt;
&lt;p&gt;In classic Gang of Four (GoF) object-oriented languages like Java, the Builder is essential for avoiding the &amp;ldquo;telescoping constructor&amp;rdquo; anti-pattern (where you have a dozen different initializers for every combination of parameters).&lt;/p&gt;
&lt;p&gt;However, in modern Swift, the classic Builder pattern is often redundant. Swift’s native features—like named parameters, default values, and structs—solve the telescoping constructor problem out of the box. Therefore, when we use the Builder pattern in Swift today, it usually takes on one of three highly optimized, modern forms.&lt;/p&gt;</description></item></channel></rss>