<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Design Patterns]]></title><description><![CDATA[Design Patterns]]></description><link>https://strategydesign.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Tue, 15 Sep 2026 11:48:22 GMT</lastBuildDate><atom:link href="https://strategydesign.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Rocket Science Made Simple: Mastering Strategy Pattern with Rocket Behaviors]]></title><description><![CDATA[1. Inheritance is Not Rocket Science (But Still a Problem)
Imagine you're building a simulation of rockets. You start with a Rocket superclass and create subclasses like CargoRocket, WarRocket, and ExplorerRocket

But soon you realize different rocke...]]></description><link>https://strategydesign.hashnode.dev/rocket-science-made-simple-mastering-strategy-pattern-with-rocket-behaviors</link><guid isPermaLink="true">https://strategydesign.hashnode.dev/rocket-science-made-simple-mastering-strategy-pattern-with-rocket-behaviors</guid><category><![CDATA[strategy design pattern]]></category><category><![CDATA[design patterns]]></category><category><![CDATA[low level design]]></category><category><![CDATA[Spring Boot]]></category><dc:creator><![CDATA[Vijay Belwal]]></dc:creator><pubDate>Sun, 20 Apr 2025 17:17:15 GMT</pubDate><content:encoded><![CDATA[<h2 id="heading-1-inheritance-is-not-rocket-science-but-still-a-problem"><strong>1. Inheritance is Not Rocket Science (But Still a Problem)</strong></h2>
<p>Imagine you're building a simulation of rockets. You start with a <code>Rocket</code> superclass and create subclasses like <code>CargoRocket</code>, <code>WarRocket</code>, and <code>ExplorerRocket</code></p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1745168561897/d847fb77-5851-40ed-a709-09646273f924.png" alt class="image--center mx-auto" /></p>
<p>But soon you realize different rockets fly differently. One uses boosters, another uses ion propulsion, and one even glides. Modifying each subclass means code duplication or fragile inheritance trees.</p>
<h2 id="heading-2-interfaces-alone-cant-handle-this-orbit"><strong>2. Interfaces Alone Can't Handle This Orbit</strong></h2>
<p>You try separating flying behavior into an interface:</p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1745168687584/fb26c22c-7c75-462e-bd63-cb133682ee77.png" alt class="image--center mx-auto" /></p>
<p>Then implement it in rockets. But now each rocket has to implement a unique fly behavior. Still messy. You’re repeating logic and scattering behavior everywhere.</p>
<h2 id="heading-3-design-principle-identify-what-varies"><strong>3. Design Principle: Identify What Varies</strong></h2>
<p>We notice that <strong>flying behavior varies</strong>, but <strong>launching doesn’t</strong>. So we extract flying behavior:</p>
<blockquote>
<p>"Identify the aspects that vary and separate them from what stays the same."</p>
</blockquote>
<p>This leads us to the Strategy Pattern.</p>
<h2 id="heading-4-the-strategy-pattern-a-rocket-smart-move"><strong>4. The Strategy Pattern: A Rocket-Smart Move</strong></h2>
<p>We encapsulate flying algorithms into separate strategy classes:</p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1745169050373/90c57f41-0a80-4e62-8f68-da6ec405918d.png" alt class="image--center mx-auto" /></p>
<p>Then inject the behavior into our <code>Rocket</code></p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1745169094841/4addba7c-f6c9-454c-ae0b-50c42551786f.png" alt class="image--center mx-auto" /></p>
<h2 id="heading-5-adding-new-rocket-behaviors-just-plug-and-play"><strong>5. Adding New Rocket Behaviors? Just Plug and Play</strong></h2>
<p>Need an eco-friendly rocket with solar sail? Add a new strategy:</p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1745169152684/ba2938ae-3d00-4e67-b037-06db69dcbae8.png" alt class="image--center mx-auto" /></p>
<p>No need to touch the <code>Rocket</code> class and violate open/closed principle. Just plug in the new strategy:</p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1745169228024/88a3958f-9a83-4ae0-812a-7875cf38fb11.png" alt class="image--center mx-auto" /></p>
<h2 id="heading-6-strategy-pattern-simplified"><strong>6. Strategy Pattern Simplified</strong></h2>
<p><strong>Definition:</strong> Strategy Pattern is a design pattern that lets you define a family of interchangeable algorithms, encapsulate each one in a separate class, and make them interchangeable in the object that uses them.</p>
<p><strong>What Problem It Solves:</strong> When a class has multiple behaviors that may vary independently (like different flying styles of rockets), hardcoding or subclassing becomes messy and rigid.</p>
<p><strong>How It Solves It:</strong> It separates the varying behavior (e.g., flying style) into individual strategy classes and uses composition to inject them into the main class (e.g., <code>Rocket</code>). This makes the behavior interchangeable at runtime and easier to extend or modify without altering the core class.</p>
<h2 id="heading-7-recap"><strong>7. Recap</strong></h2>
<p>The Strategy Pattern lets us:</p>
<ul>
<li><p>Swap behaviors at runtime</p>
</li>
<li><p>Isolate variable logic</p>
</li>
<li><p>Scale new algorithms easily</p>
</li>
</ul>
<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text">Next time your rocket simulation needs flexibility, don’t subclass. <strong>Strategize.</strong></div>
</div>]]></content:encoded></item></channel></rss>