Quick reference for algorithms, complexities & data structures
A class is a template or blueprint. An object is an instantiated instance of that class in memory.
Bundling data and methods that work on that data within one unit, restricting direct access to some of the object's components.
The condition of an object at a specific moment in time, defined by the values of all its attributes.
One object is linked to multiple objects of another class. Typically implemented using collections (e.g., Arrays, Lists) on the "1" side.
Multiple objects natively linked to multiple other objects. Requires careful handling to avoid infinite loops during serialization.
A "whole/part" relationship. The part can exist independently of the whole. Denoted by a hollow diamond.
A strict whole/part relationship. The part's lifecycle is bound to the whole. If the whole is destroyed, the parts are destroyed. Denoted by a filled diamond.
Creating subclasses that inherit attributes and methods from a superclass. Formats an "is-a" relationship.
Disjoint: An object can only belong to ONE
subclass.
Overlapping: An object can belong to multiple subclasses
simultaneously.
Inheriting from multiple base classes. Leads to complexities like the Diamond Problem, resolved via language-specific mechanisms (e.g., Interfaces, Mixins, MRO).
| UML Concept | Relational Strategy | Implementation |
|---|---|---|
| Class | Table | Rows = objects, Columns = attributes |
| 1:N Association | Foreign Key | Stored on the "N" (many) side table pointing to the "1" side PK |
| M:N Association | Junction Table | A new table containing Foreign Keys to both original tables |
| Class Inheritance | Table per Class / Single Table | Depending on strategy: shared PKs between parent/child tables or a nullable monolithic table |
Testing visual elements, user flows, and integrations. Often involves Mocks and Stubs to isolate the frontend logic from the backend data.