Items in category design patterns

React Design Patterns: A Practical Reference

Design Patterns
React Design Patterns: A Practical Reference
Image generated by Gemini

Master the six essential React design patterns that solve real problems in modern applications. From Composition and Custom Hooks to Providers, Compound Components, Server/Client Separation, and Suspense—each pattern includes real-world analogies, practical code examples, and visual diagrams.

Design Patterns in JavaScript, Python, and Rust

Design Patterns
Design Patterns in JavaScript, Python, and Rust
Image generated by ChatGPT

A practical walkthrough of the 5 SOLID principles and 23 GoF design patterns, with side-by-side examples in JavaScript, Python, and Rust. The goal is simple: see the same idea expressed in three different type systems and paradigms, and let the differences teach you something.

Flyweight pattern using Mixins

Design Patterns
Flyweight pattern using Mixins

In my previous article among other patters I was telling about Flyweight. That is about the objects designed so to minimize memory use by sharing as much data as possible with other similar objects. You can find plenty of Flyweight implementation examples in Internet, though it will be mostly variations of Multiton, a collection (map) keeping only instance per every identical object. And I decided to follow that unwritten rule as it seems to be the simplest way to show the idea. In some cases it is much more efficient to share not the instance itself, but weighty parts among the instances. Imagine, you have user object containing properties and methods relevant for any user. However registered user has extended set of properties and methods. Moderator or admin contain even more.

Design Patterns by PHP and JavaScript examples

Design Patterns
Design Patterns by PHP and JavaScript examples
Image generated by Gemini

After having your project fully tested, deployed and running, it seems the application architecture is pretty good enough. All the requirements met and everybody is happy. But then as it happens, the requirements change and you, all of sudden, find yourself in the time of troubles. It comes out that some modules easier to hack than to modify. Change of other ones brings endless changes in a cascade of dependent modules. Or you change one module and whole the application starts to collapse like a house of cards. And, of course, you find out that you can’t reuse already written modules for the new tasks, because the encapsulation of the desired parts would take too much risk and work. Robert C. Martin was very accurate naming those symptoms of rotting design as Viscosity, Rigidity, Fragility and Immobility