Flutter Community
Published in

Flutter Community

Flutter Design Patterns: 19 — Flyweight

An overview of the Flyweight design pattern and its implementation in Dart and Flutter

Table of Contents

  • What is the Flyweight design pattern?
  • Analysis
  • Implementation
  • Other articles in this series
  • Your contribution

What is the Flyweight design pattern?

Use sharing to support large numbers of fine-grained objects efficiently.

Let’s take an object-oriented document editor as an example. For document elements like tables, images or figures, separate objects are created. However, for text elements (individual characters) this is not feasible even though it promotes flexibility: characters and any other embedded elements could be treated uniformly, and the application could be extended to support new character sets very easily. The reason is simple — limitations of the hardware. Usually, a document contains hundreds of thousands of character objects which would consume a lot of memory and it could lead to unexpected crashes, for instance, when the document is being edited and eventually there would be no memory left for new characters or any other type of embedded objects. How this kind of object-oriented document editor could be implemented, then?


The general structure of the Flyweight design pattern looks like this:

Structure of the Flyweight design pattern (source)
  • FlyweightFactory — creates and manages flyweight objects. When a client calls the factory, it checks whether the specific flyweight object exists. If yes, it is simply returned to the client, otherwise, a new instance of the flyweight object is created and then returned;
  • Context — contains the extrinsic state, unique across all original objects;
  • Client — computes or stores the extrinsic state of flyweight(s) and maintains a reference to it/them.
  • The objects drain all available RAM on a target device;
  • The objects contain duplicate states which can be extracted and shared between multiple objects;
  • Many groups of objects could be replaced by a few shared objects once the extrinsic state is removed;
  • The application doesn’t depend on object identity. Since flyweight objects are shared, conceptually distinct objects could be considered the same object.


  • A flyweight factory would be used which creates a single object per shape.

Class diagram

The class diagram below shows the implementation of the Flyweight design pattern:

Class Diagram — Implementation of the Flyweight design pattern


A special kind of class — enumeration — to define different shape types.



An interface that defines the render() method to be implemented by concrete shape classes. Dart language does not support the interface as a class type, so we define an interface by creating an abstract class and providing a method header (name, return type, parameters) without the default implementation.


Concrete shapes

  • Circle — a specific implementation of the IPositionedShape interface representing the shape of a circle.


A simple factory class that defines the createShape() method to create a concrete shape by providing its type.



A flyweight factory class that keeps track of all the flyweight objects and creates them if needed.



First of all, a markdown file is prepared and provided as a pattern’s description:


Your contribution

👏 Press the clap button below to show your support and motivate me to write better!
💬 Leave a response to this article by providing your insights, comments or wishes for the series.
📢 Share this article with your friends, colleagues on social media.
➕ Follow me on Medium.
⭐ Star the Github repository.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store