A defense of proper object-oriented design, arguing that objects should encapsulate both state and behaviour rather than acting as mere data containers. Using the example of an invoice, the author explains that exposing behaviour like `invoice.pay(anAmount)` is the correct OOP approach because the ability to be paid is an inherent property of an invoice. The post pushes back against the common pattern of anemic domain models where services hold all business logic and objects are just bags of state.
