Mastering Frontend Design Patterns: Singleton, Proxy, Strategy, Observer Explained

This article introduces core frontend design patterns—including Singleton, Proxy, Strategy, and Observer—explains their underlying principles such as Single Responsibility and Open/Closed, and provides practical code examples and visual illustrations to help developers apply them effectively.

JD.com Experience Design Center
JD.com Experience Design Center
JD.com Experience Design Center
Mastering Frontend Design Patterns: Singleton, Proxy, Strategy, Observer Explained

Design Patterns

Design patterns are a high‑level topic often discussed among programmers, especially in languages that treat functions as first‑class objects where many patterns rely on object polymorphism, such as Singleton and Strategy. Their structures differ from traditional OOP patterns and are often used implicitly.

1 Common Principles

Key design principles include Single Responsibility Principle (SRP) and Open‑Closed Principle (OCP). This article focuses on these two.

1.1 Single Responsibility Principle (SRP)

An object or method should do only one thing. When a method has multiple motivations, it has multiple responsibilities, increasing the likelihood of changes during evolving requirements.

SRP reduces class or object complexity, promotes reuse, and eases unit testing. However, it can increase codebase complexity by creating many small objects that need to interact.

1.2 Open‑Closed Principle (OCP)

Objects (classes, modules, functions) should be open for extension but closed for modification. Even if the code is minified or obfuscated, its stable behavior should remain unchanged while new features are added without altering existing code.

2 Singleton Pattern

The Singleton pattern ensures a class has only one instance and provides a global access point.

2.1 Example: Login Modal

In a video‑site, the login button opens a unique login dialog. Creating the DOM node at page load and hiding it (display:none) wastes resources if the user never logs in. A better approach creates the dialog only when the button is clicked, and reuses the same instance thereafter.

To avoid unnecessary DOM nodes, a variable tracks whether the login layer has been created. The creation and singleton‑management responsibilities are separated into two functions, improving decoupling and performance.

2.2 Other Scenarios

Singletons are useful in state‑management tools like Redux or Vuex, global objects like window, and shared caches.

Multiple references to a library (e.g., jQuery, lodash) use a single instance.

Vuex/Redux store a single state; MobX uses multiple stores.

2.3 Summary

The getSingle function demonstrates closures and higher‑order functions. Properly applied, Singleton creates objects only when needed and keeps creation and management responsibilities separate.

3 Proxy Pattern

The Proxy pattern provides a surrogate object that controls access to the original object, acting as an intermediary.

3.1 Example: Image Preloading

Instead of setting src directly, a placeholder image is shown while the real image loads asynchronously. A proxy object handles the preloading, keeping the original MyImage class focused on its core responsibility.

3.2 Example: Request Merging

When many checkboxes trigger file‑sync requests, a proxy function can batch requests within a time window (e.g., 2 seconds) and send a single request, reducing server load.

3.3 Summary

Proxy adds behavior without modifying the original object's interface, satisfying both SRP and OCP.

4 Strategy Pattern

Strategy defines a family of algorithms, encapsulates each one, and makes them interchangeable.

4.1 Example: Multi‑Condition Business Logic

Complex order routing can be refactored using a Map to associate conditions with handling functions, reducing nested if‑else chains.

4.2 Example: Form Validation

Validation rules (non‑empty username, password length, phone format) are encapsulated as separate strategy objects, making the validation logic extensible and reusable.

4.3 Summary

Using Strategy eliminates large conditional blocks, clarifies responsibilities, and allows reuse of validation logic across the system.

5 Observer Pattern

Observer establishes a one‑to‑many dependency so that when one object changes, all dependents are notified.

5.1 Example: Website Login

Modules like header, navigation, and cart all need user info after login. By publishing a login‑success event, each module can subscribe and react independently, decoupling them from the login implementation.

5.2 Summary

Observer provides temporal and structural decoupling, widely used in asynchronous programming, but excessive subscriptions can increase memory usage and make debugging harder.

6 Conclusion

Just as recipes guide cooking, design patterns guide software development. Frontend developers commonly use Singleton, Proxy, Strategy, and Observer to separate mutable and immutable aspects of code, achieving flexibility where needed and stability where not.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

design-patternsfrontendProxySingletonStrategyObserver
JD.com Experience Design Center
Written by

JD.com Experience Design Center

Professional, creative, passionate about design. The JD.com User Experience Design Department is committed to creating better e-commerce shopping experiences.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.