I've always thought of OOP as structuring a program the same way you'd structure a business. There are distinct divisions with responsibilities and internal sta

I've always thought of OOP as structuring a program the same way you'd structure a business. There are distinct divisions with responsibilities and internal state, with somewhat well defined ways to communicate with each other. Part of why OOP got so popular in software businesses is because it removes an impedance mismatch between the functions of business and the software it produces. In this view, UML is a kind of intermediate bytecode between business planning and software planning. Where it falls apart, IMO, is that UML is too granular for business functions, and it enforces a probably suboptimal OOP way of approaching technical problems.