In coding & [[Systems Thinking]], system components can either be **stateful** or **stateless**. Stateless objects have no inherent "state", they just *are*. Stateful objects *do* have inherent "states" (or *configurations*) that change them in some way. > [!example] > - **Hammer** = stateless. A hammer is a hammer is a hammer. There are not various *configurations*. > - **Power drill** = stateful. Is it on? Is the battery in or out? What drill bit is in it? There are many *configurations*. There's no "better" in terms of statefulness or statelessness. Sometimes a hammer is better. Sometimes you need the drill. They each come with [[Tradespace|trade offs]]. Stateless objects are inherently [[Simplicity|simpler]], but that simplicity can come at the cost of [[Simple vs Easy|ease]] in some cases. Stateful objects may be more custom-fit to your needs, but are less [[Modularity|modular]] and less [[Systems Composability|composable]]. ## Misc - [[RESTful API]]s are stateless. They aren't supposed to depend on a shared state between the client & server - [[OPM|Object Process Methodology]] describes itself as a depiction of *stateful* objects and the processes that transform them. **** # More ## Source - self6