Functional, stateless design organizes an application around expressions, immutable data, and functions that transform values. Rather than treating objects as bundles of changing state and behavior, model the current state as simple data and make operations return an updated value. This approach aims for code that is easier to write, understand, test, and maintain. section 2.1 section 2.1.3
A retail basket shows the shift clearly. An object-oriented design might place AddItem, Clear, and Checkout methods alongside private mutable basket state. A functional design keeps the basket in an immutable record and places AddItem, Clear, and Checkout in a module. Calling an operation produces a new basket instead of modifying the old one. section 2.1.3
Use the functional-first style as a practical default:
- Prefer expressions and immutable values over statements and mutable variables. section 2.1 section 16.1.4
- Separate data types from the functions that operate on them instead of fusing state and behavior in classes. section 2.1.3
- Use composition, currying, lambdas, and pattern matching where they make functions more flexible. section 2.1
- Keep procedural or object-oriented features available for interoperation and uncommon corner cases rather than treating them as forbidden. section 1.2 section 11.1.1
HTTP as a function-shaped boundary
Web programming fits this style because an HTTP request identifies an operation and supplies inputs; the server returns a response as its result. A request’s verb, route, body, query string, cookies, and headers act like function-call details, while the response body, status code, and headers represent the returned result. section 13.1
Adopt the approach incrementally. Rewrite a familiar module or vertical slice, preserve the known domain, and reconsider its design instead of performing a like-for-like port. Avoid mutable variables and statements where possible; use immutable values and expressions to compare clarity in the new version. section 16.1.4
Figure 11.1 Illustrating the clear distinction between the object orientated (OO) and functional programming (FP) halves of F#
Compare the distinct functional and object-oriented halves of F# when deciding where immutable, stateless design should lead and where interoperation needs OO constructs. section 11.1.1
