<?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>Structural Design Patterns on Abhishek Shukla</title><link>https://abhishekshukla.dev/tags/structural-design-patterns/</link><description>Recent content in Structural Design Patterns on Abhishek Shukla</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 26 Jun 2026 14:30:00 +0530</lastBuildDate><atom:link href="https://abhishekshukla.dev/tags/structural-design-patterns/index.xml" rel="self" type="application/rss+xml"/><item><title>The Adapter Design Pattern in Swift: Bridging Legacy Code to Modern APIs</title><link>https://abhishekshukla.dev/blog/adapter-design-pattern/</link><pubDate>Wed, 24 Jun 2026 11:20:00 +0530</pubDate><guid>https://abhishekshukla.dev/blog/adapter-design-pattern/</guid><description>&lt;p&gt;In the real world, you cannot always control the code you work with. You will frequently need to integrate legacy systems, older Objective-C frameworks, or external SDKs into your modern Swift application.&lt;/p&gt;
&lt;p&gt;The problem arises when these external systems have interfaces that are completely incompatible with your app&amp;rsquo;s existing architecture. If you force your app to accommodate these legacy interfaces directly—like dealing with &lt;code&gt;NSArray&lt;/code&gt;, untyped dictionaries, and completion handlers—your code quickly becomes a tightly coupled, unsafe mess.&lt;/p&gt;</description></item><item><title>The Decorator Design Pattern in Swift: Enhancing Objects Dynamically</title><link>https://abhishekshukla.dev/blog/decorator-design-pattern/</link><pubDate>Thu, 25 Jun 2026 12:51:58 +0530</pubDate><guid>https://abhishekshukla.dev/blog/decorator-design-pattern/</guid><description>&lt;p&gt;As your application grows, you often need to add new responsibilities to existing objects. The default approach for many developers is subclassing. However, subclassing is static and applies to an entire class. If you need to combine multiple different behaviors, subclassing leads to a massive, unmaintainable &amp;ldquo;subclass explosion.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;The &lt;strong&gt;Decorator&lt;/strong&gt; pattern (also known as a Wrapper) solves this. It is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.&lt;/p&gt;</description></item><item><title>The Facade Design Pattern in Swift: Simplifying Complex Systems</title><link>https://abhishekshukla.dev/blog/facade-design-pattern/</link><pubDate>Fri, 26 Jun 2026 14:30:00 +0530</pubDate><guid>https://abhishekshukla.dev/blog/facade-design-pattern/</guid><description>&lt;p&gt;Modern iOS applications rely on multiple subsystems: networking, local databases, image caching, and third-party SDKs. If your UI or business logic interacts with all of these internal classes directly, your code becomes incredibly dense and difficult to read.&lt;/p&gt;
&lt;p&gt;The &lt;strong&gt;Facade&lt;/strong&gt; design pattern is a structural pattern that provides a simplified, high-level interface to a complex body of code. It hides the underlying complexity of multiple subsystems behind a single, easy-to-use class.&lt;/p&gt;</description></item></channel></rss>