wiki143 - User contributions [en]

Flyweight pattern

2025-10-18T02:14:57Z

2605:8D80:6A21:9026:886A:BD7C:FA60:99CB: /* C++ */

{{Short description|Software design pattern for objects}}
{{more footnotes|date=May 2008}}
[[File:Linux-Mint-20-MATE-writer.png|alt=A screenshot of LibreOffice's Writer package.|thumb|Text editors, such as [[LibreOffice Writer]], often use the flyweight pattern.]]
In [[computer programming]], the '''flyweight''' [[software design pattern]] refers to an [[Object (computer science)|object]] that minimizes [[Computer memory|memory]] usage by sharing some of its data with other similar objects. The flyweight pattern is one of twenty-three well-known ''[[Design Patterns|GoF design patterns]]''.<ref name="GoF">{{cite book|author=Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides|url=https://archive.org/details/designpatternsel00gamm/page/195|title=Design Patterns: Elements of Reusable Object-Oriented Software|publisher=Addison Wesley|year=1994|isbn=978-0-201-63361-0|pages=[https://archive.org/details/designpatternsel00gamm/page/195 195ff]}}</ref> These patterns promote flexible object-oriented software design, which is easier to implement, change, test, and reuse.

In other contexts, the idea of sharing data structures is called [[hash consing]].

The term was first coined, and the idea extensively explored, by [[Paul Calder]] and [[Mark Linton]] in 1990<ref>{{cite book|last=Gamma|first=Erich|title=Design Patterns: Elements of Reusable Object-Oriented Software|title-link=Design Patterns (book)|author2=Richard Helm|author3=Ralph Johnson|author4=John Vlissides|publisher=[[Addison-Wesley]]|year=1995|isbn=978-0-201-63361-0|pages=[https://archive.org/details/designpatternsel00gamm/page/205 205–206]|author-link=Erich Gamma|author2-link=Richard Helm|author3-link=Ralph Johnson (computer scientist)|author4-link=John Vlissides}}
</ref> to efficiently handle glyph information in a [[WYSIWYG|WYSIWYG document editor]].<ref>
{{cite conference|last1=Calder|first1=Paul R.|last2=Linton|first2=Mark A.|title=Proceedings of the 3rd annual ACM SIGGRAPH symposium on User interface software and technology - UIST '90 |date=October 1990|chapter=Glyphs: Flyweight Objects for User Interfaces|conference=The 3rd Annual [[ACM SIGGRAPH]] Symposium on User Interface Software and Technology|location=Snowbird, Utah, United States|pages=92–101|doi=10.1145/97924.97935|isbn=0-89791-410-4}}
</ref> Similar techniques were already used in other systems, however, as early as 1988.<ref>
{{cite conference|last1=Weinand|first1=Andre|last2=Gamma|first2=Erich|last3=Marty|first3=Rudolf|year=1988|title=ET++—an object oriented application framework in C++|conference=[[OOPSLA]] (Object-Oriented Programming Systems, Languages and Applications)|location=San Diego, California, United States|pages=46–57|citeseerx=10.1.1.471.8796|doi=10.1145/62083.62089|isbn=0-89791-284-5}}
</ref>

==Overview==
The flyweight pattern is useful when dealing with a large number of objects that share simple repeated elements which would use a large amount of memory if they were individually embedded. It is common to hold shared data in external [[data structure]]s and pass it to the objects temporarily when they are used.

A classic example are the data structures used representing characters in a [[word processor]]. Naively, each character in a document might have a [[glyph]] object containing its font outline, font metrics, and other formatting data. However, this would use hundreds or thousands of bytes of memory for each character. Instead, each character can have a [[reference (computer science)|reference]] to a glyph object shared by every instance of the same character in the document. This way, only the position of each character needs to be stored internally.

As a result, flyweight objects can:<ref>{{Cite web|date=2019-01-28|title=Implementing Flyweight Patterns in Java|url=https://www.developer.com/design/implementing-flyweight-patterns-in-java/|access-date=2021-06-12|website=Developer.com|language=en-US}}</ref>
* store ''intrinsic'' state that is invariant, context-independent and shareable (for example, the code of character 'A' in a given character set)
* provide an interface for passing in ''extrinsic'' state that is variant, context-dependent and can't be shared (for example, the position of character 'A' in a text document)

Clients can reuse <code>Flyweight</code> objects and pass in extrinsic state as necessary, reducing the number of physically created objects.

=== Structure ===
[[File:w3sDesign Flyweight Design Pattern UML.jpg|frame|none|A sample UML class and [[sequence diagram]] for the Flyweight design pattern.<ref>{{cite web|title=The Flyweight design pattern - Structure and Collaboration|url=http://w3sdesign.com/?gr=s06&ugr=struct|website=w3sDesign.com|access-date=2017-08-12}}</ref>]]

The above [[UML]] [[class diagram]] shows:

* the <code>Client</code> class, which uses the flyweight pattern
*the <code>FlyweightFactory</code> class, which [[Factory class|creates and shares <code>Flyweight</code> objects]]
* the <code>Flyweight</code> [[Interface (computing)|interface]], which takes in extrinsic state and performs an operation
*the <code>Flyweight1</code> class, which implements <code>Flyweight</code> and stores intrinsic state

The sequence diagram shows the following [[Runtime (program lifecycle phase)|run-time]] interactions:

# The <code>Client</code> object calls <code>getFlyweight(key)</code> on the <code>FlyweightFactory</code>, which returns a <code>Flyweight1</code> object.
# After calling <code>operation(extrinsicState)</code> on the returned <code>Flyweight1</code> object, the <code>Client</code> again calls <code>getFlyweight(key)</code> on the <code>FlyweightFactory</code>.
# The <code>FlyweightFactory</code> returns the already-existing <code>Flyweight1</code> object.

== Implementation details ==
There are multiple ways to implement the flyweight pattern. One example is mutability: whether the objects storing extrinsic flyweight state can change.

[[Immutable]] objects are easily shared, but require creating new extrinsic objects whenever a change in state occurs. In contrast, mutable objects can share state. Mutability allows better object reuse via the caching and re-initialization of old, unused objects. Sharing is usually nonviable when state is highly variable.

Other primary concerns include retrieval (how the end-client accesses the flyweight), [[caching]] and [[Concurrency (computer science)|concurrency]].

=== Retrieval ===
The [[Factory (object-oriented programming)|factory]] interface for creating or reusing flyweight objects is often a [[Facade pattern|facade]] for a complex underlying system. For example, the factory interface is commonly implemented as a [[Singleton pattern|singleton]] to provide global access for creating flyweights.

Generally speaking, the retrieval algorithm begins with a request for a new object via the factory interface.

The request is typically forwarded to an appropriate [[Cache (computing)|cache]] based on what kind of object it is. If the request is fulfilled by an object in the cache, it may be reinitialized and returned. Otherwise, a new object is instantiated. If the object is partitioned into multiple extrinsic sub-components, they will be pieced together before the object is returned.

=== Caching ===
There are two ways to [[Cache (computing)|cache]] flyweight objects: maintained and unmaintained caches.

Objects with highly variable state can be cached with a [[FIFO (computing and electronics)|FIFO]] structure. This structure maintains unused objects in the cache, with no need to search the cache.

In contrast, unmaintained caches have less upfront overhead: objects for the caches are initialized in bulk at compile time or startup. Once objects populate the cache, the object retrieval algorithm might have more overhead associated than the push/pop operations of a maintained cache.

When retrieving extrinsic objects with immutable state one must simply search the cache for an object with the state one desires. If no such object is found, one with that state must be initialized. When retrieving extrinsic objects with mutable state, the cache must be searched for an unused object to reinitialize if no used object is found. If there is no unused object available, a new object must be instantiated and added to the cache.

Separate caches can be used for each unique subclass of extrinsic object. Multiple caches can be optimized separately, associating a unique search algorithm with each cache. This object caching system can be encapsulated with the [[Chain-of-responsibility pattern|chain of responsibility]] pattern, which promotes loose coupling between components.

=== Concurrency ===
Special consideration must be taken into account where flyweight objects are created on multiple threads. If the list of values is finite and known in advance, the flyweights can be instantiated ahead of time and retrieved from a container on multiple threads with no contention. If flyweights are instantiated on multiple threads, there are two options:

# Make flyweight instantiation single-threaded, thus introducing contention and ensuring one instance per value.
# Allow concurrent threads to create multiple flyweight instances, thus eliminating contention and allowing multiple instances per value.

To enable safe sharing between clients and threads, flyweight objects can be made into [[immutable]] [[value object]]s, where two instances are considered equal if their values are equal.

== Examples ==

=== C# ===
In this example, every instance of the <code>MyObject</code> class uses a <code>Pointer</code> class to provide data.
<syntaxhighlight lang="csharp">
// Defines Flyweight object that repeats itself.
public class Flyweight
{
public string Name { get; set; }
public string Location { get; set; }
public string Website { get; set; }
public byte[] Logo { get; set; }
}

public static class Pointer
{
public static readonly Flyweight Company = new Flyweight { Name = "ABC", Location = "XYZ", Website = "www.example.com" };
}

public class MyObject
{
public string Name { get; set; }
public string Company => Pointer.Company.Name;
}
</syntaxhighlight>

=== C++ ===
The C++ [[Standard Template Library]] provides several containers that allow unique objects to be mapped to a key. The use of containers helps further reduce memory usage by removing the need for temporary objects to be created.

<syntaxhighlight lang="c++">
import std;

template <typename K, typename V>
using TreeMap = std::map<K, V>;
using String = std::string;
using StringView = std::string_view;
template <typename K, typename V>
using HashMap = std::unordered_map<K, V>;

// Instances of Tenant will be the Flyweights
class Tenant {
private:
const String name;
public:
explicit Tenant(StringView name):
name{name} {}

[[nodiscard]]
String getName() const noexcept {
return name;
}
};

// Registry acts as a factory and cache for Tenant flyweight objects
class Registry {
private:
HashMap<String, Tenant> tenants;
public:
Registry() = default;

[[nodiscard]]
Tenant& findByName(StringView name) {
if (!tenants.contains(name)) {
tenants[name] = Tenant{name};
}
return tenants[name];
}
};

// Apartment maps a unique tenant to their room number.
class Apartment {
private:
TreeMap<int, Tenant*> occupants;
Registry registry;
public:
Apartment() = default;

void addOccupant(StringView name, int room) {
occupants[room] = &registry.findByName(name);
}

void printTenants() {
// room: int, tenant: Tenant
for (const auto& [room, tenant] : occupants) {
std::println("{} occupies room {}", tenant.name(), room);
}
}
};

int main(int argc, char* argv[]) {
Apartment apartment;
apartment.addOccupant("David", 1);
apartment.addOccupant("Sarah", 3);
apartment.addOccupant("George", 2);
apartment.addOccupant("Sarah", 12);
apartment.addOccupant("Michael", 10);
apartment.printTenants();

return 0;
}
</syntaxhighlight>

=== PHP ===
<syntaxhighlight lang="php"><?php

class CoffeeFlavour {

private static array $CACHE = [];

private function __construct(private string $name) {}

public static function intern(string $name): self {
self::$CACHE[$name] ??= new self($name);
return self::$CACHE[$name];
}

public static function flavoursInCache(): int {
return count(self::$CACHE);
}

public function __toString(): string {
return $this->name;
}

}

class Order {

private function __construct(
private CoffeeFlavour $flavour,
private int $tableNumber
) {}

public static function create(string $flavourName, int $tableNumber): self {
$flavour = CoffeeFlavour::intern($flavourName);
return new self($flavour, $tableNumber);
}

public function __toString(): string {
return "Serving {$this->flavour} to table {$this->tableNumber}";
}
}

class CoffeeShop {

private array $orders = [];

public function takeOrder(string $flavour, int $tableNumber) {
$this->orders[] = Order::create($flavour, $tableNumber);
}

public function service() {
print(implode(PHP_EOL, $this->orders).PHP_EOL);
}
}

$shop = new CoffeeShop();
$shop->takeOrder("Cappuccino", 2);
$shop->takeOrder("Frappe", 1);
$shop->takeOrder("Espresso", 1);
$shop->takeOrder("Frappe", 897);
$shop->takeOrder("Cappuccino", 97);
$shop->takeOrder("Frappe", 3);
$shop->takeOrder("Espresso", 3);
$shop->takeOrder("Cappuccino", 3);
$shop->takeOrder("Espresso", 96);
$shop->takeOrder("Frappe", 552);
$shop->takeOrder("Cappuccino", 121);
$shop->takeOrder("Espresso", 121);
$shop->service();
print("CoffeeFlavor objects in cache: ".CoffeeFlavour::flavoursInCache().PHP_EOL);
</syntaxhighlight>

==See also==
* [[Copy-on-write]]
* [[Memoization]]
* [[Multiton]]

== References ==
{{reflist}}

{{Design Patterns Patterns}}

{{DEFAULTSORT:Flyweight Pattern}}
[[Category:Articles with example Java code]]
[[Category:Software design patterns]]
[[Category:Software optimization]]

Object–relational mapping

2025-10-17T20:22:39Z

2605:8D80:6A21:9026:886A:BD7C:FA60:99CB:

{{short description|Programming technique}}
{{Distinguish|Object–role modeling}}
{{Use dmy dates|date=June 2019}}
{{More citations needed|date=May 2009}}
'''Object–relational mapping''' ('''ORM''', '''O/RM''', and '''O/R mapping tool''') in [[computer science]] is a [[Computer programming|programming]] technique for converting data between a [[relational database]] and the memory (usually the [[Memory management#HEAP|heap]]) of an [[Object-oriented programming|object-oriented]] programming language. This creates, in effect, a virtual [[object database]] that can be used from within the program.

In [[object-oriented programming]], [[data management|data-management]] tasks act on [[object (computer science)|object]]s that combine [[scalar (computing)|scalar]] values into objects. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person [[Object (computer science)|object]]" with an [[attribute (computing)|attribute/field]] to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. Each such address-book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various [[Method (computer programming)|methods]] can be associated with the object, such as methods to return the preferred phone number, the home address, and so on.

By contrast, relational databases, such as [[SQL]], group scalars into [[tuples]], which are then enumerated in [[Table (database)|tables]]. Tuples and objects have some general similarity, in that they are both ways to collect values into named fields such that the whole collection can be manipulated as a single compound entity. They have many differences, though, in particular: lifecycle management (row insertion and deletion, versus [[Garbage collection (computer science)|garbage collection]] or [[reference counting]]), references to other entities (object references, versus foreign key references), and inheritance (non-existent in relational databases). As well, objects are managed on-heap and are under full control of a single process, while database tuples are shared and must incorporate locking, merging, and retry. Object–relational mapping provides automated support for mapping tuples to objects and back, while accounting for all of these differences.<ref name="hibernate-orm-overview">
{{cite web |title=What is Object/Relational Mapping? |url=http://www.hibernate.org/about/orm |access-date=27 January 2022 |work=Hibernate Overview |publisher=JBOSS Hibernate |language=en-US}}
</ref>

The heart of the problem involves translating the logical representation of the objects into an atomized form that is capable of being stored in the database while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be [[persistence (computer science)|persistent]].<ref name=hibernate-orm-overview />

==Overview==
Implementation-specific details of storage drivers are generally wrapped in an API in the programming language in use, exposing methods to interact with the storage medium in a way which is simpler and more in line with the paradigms of surrounding code.

The following is a simple example, written in [[C Sharp (programming language)|C#]] code, to execute a query written in [[SQL]] using a database engine.

<syntaxhighlight lang="csharp">
using System.Collections.Generic;

string sql = "SELECT id, first_name, last_name, phone, birth_date, sex, age FROM persons WHERE id = 10";
List<Person> result = context.Persons.FromSqlRaw(sql).ToList();
string name = result[0]["first_name"];
</syntaxhighlight>

In contrast, the following makes use of an ORM-job API which makes it possible to write code that naturally makes use of the features of the language.

<syntaxhighlight lang="csharp">
Person person = repository.GetPerson(10);
string firstName = person.GetFirstName();
</syntaxhighlight>

The case above makes use of an object representing the storage repository and methods of that object. Other frameworks might provide code as static methods, as in the example below, and yet other methods may not implement an object-oriented system at all. Often the choice of paradigm is made for the best fit of the ORM into the surrounding language's design principles.

<syntaxhighlight lang="csharp">
Person person = Person.Get(10);
</syntaxhighlight>

==Comparison with traditional data access techniques==
Compared to traditional techniques of exchange between an object-oriented language and a relational database, ORM often reduces the amount of code that needs to be written.<ref>{{cite journal | date= 1998 | doi=10.1109/2.730734 | issue=11 | journal=Computer | pages=33–40 | publisher=Institute of Electrical and Electronics Engineers (IEEE) | title=Solving the Java object storage problem |quote=For this exercise, 496 lines of code were needed using the ODMG Java Binding compared to 1,923 lines of code using JDBC. | url=https://www.service-architecture.com/articles/object-relational-mapping/transparent-persistence-vs-jdbc-call-level-interface.html | vauthors=((Barry, D.)), ((Stanienda, T.)) | volume=31 }}</ref>

Disadvantages of ORM tools generally stem from the high level of [[Database abstraction layer|abstraction]] obscuring what is actually happening in the implementation code.

==Object-oriented databases==
Another approach is to use an [[object database|object-oriented database management system]] (OODBMS) or [[document-oriented database]]s such as native [[XML database]]s that provide more flexibility in data modeling. OODBMSs are databases designed specifically for working with object-oriented values. Using an OODBMS eliminates the need for converting data to and from its SQL form, as the data is stored in its original object representation and relationships are directly represented, rather than requiring [[junction table|join tables]]/operations. The equivalent of ORMs for [[document-oriented database]]s are called object-document mappers (ODMs).

Document-oriented databases also prevent the user from having to "shred" objects into table rows. Many of these systems also support the [[XQuery]] query language to retrieve datasets.

Object-oriented databases tend to be used in complex, niche applications. One of the arguments against using an OODBMS is that it may not be able to execute ad-hoc, application-independent queries.{{Citation needed|date=September 2013}} For this reason, many programmers find themselves more at home with an object-SQL mapping system, even though most object-oriented databases are able to process SQL queries to a limited extent. Other OODBMS provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving well-known query patterns.{{Citation needed|date=September 2018}}

==Challenges==
A variety of difficulties arise when considering how to match an object system to a relational database. These difficulties are referred to as the [[object–relational impedance mismatch]].<ref>[https://www.semanticscholar.org/paper/Object-Relational-Mapping-Revisited-A-Quantitative-Lorenz-Rudolph/708ac5e798b7e45b949d42e2f872549a3612e1e2 Object–Relational Mapping Revisited - A Quantitative Study on the Impact of Database Technology on O/R Mapping Strategies. M Lorenz, JP Rudolph, G Hesse, M Uflacker, H Plattner. Hawaii International Conference on System Sciences (HICSS), 4877-4886] (DOI:10.24251/hicss.2017.592)</ref>

An alternative to implementing ORM is use of the native procedural languages provided with every major database. These can be called from the client using SQL statements. The [[Data access object|Data Access Object]] (DAO) design pattern is used to abstract these statements and offer a lightweight object-oriented interface to the rest of the application.<ref>{{cite web |last=Feuerstein |first=Steven |author2=Bill Pribyl |date=September 1997 |title=Oracle PL/SQL Programming |url=http://docstore.mik.ua/orelly/oracle/prog2/ch18_05.htm |access-date=23 August 2011 |language=en-US |location=18.5 Modifying Persistent Objects}}</ref>

ORMs are limited to their predefined functionality, which may not cover all edge cases or database features. They usually mitigate this limitation by providing users with an interface to write raw queries, such as Django ORM.<ref>{{Cite web |title=Performing raw SQL queries {{!}} Django documentation |url=https://docs.djangoproject.com/en/5.1/topics/db/sql/ |access-date=2024-09-08 |website=Django Project |language=en}}</ref>

== See also ==
*[[List of object–relational mapping software]]
*[[Comparison of object–relational mapping software]]
*[[AutoFetch]] – automatic query tuning
*[[Common Object Request Broker Architecture]] (CORBA)
*[[Object database]]
*[[Object persistence]]
*[[Object–relational database]]
*[[Object–relational impedance mismatch]]
*[[Relational model]]
**[[SQL]] (Structured Query Language)
*[[Java Data Objects]] (JDO)
*[[Java Persistence API]] (JPA), now [[Jakarta Persistence]]
*[[Service Data Objects]]
*[[Entity Framework]]
*[[Active record pattern]]
*[[Data mapper pattern]]
*[[Single Table Inheritance]]

==References==
{{Reflist}}

==External links==
*[http://www.artima.com/intv/abstract3.html About ORM] by [[Anders Hejlsberg]]
*[http://www.agiledata.org/essays/mappingObjects.html Mapping Objects to Relational Databases: O/R Mapping In Detail] by [[Scott W. Ambler]]

{{Database}}

{{DEFAULTSORT:Object-Relational Mapping}}
[[Category:Object–relational mapping| ]]
[[Category:Data mapping]]
[[Category:Articles with example C Sharp code]]