Objects Hide Decisions, Data Structures Expose Them
What this concept is
Objects and data structures serve different purposes. Objects hide internal representation behind behavior. Data structures expose data and are usually manipulated by external functions. Trouble starts when code becomes a hybrid that does neither cleanly.
Why it matters here
This distinction shapes API design, boundary choices, and class responsibility. If you do not know whether you are modeling behavior or just moving data around, your design becomes muddy fast.
Concrete example
Behavior-oriented object:
cart.add_item(product)
cart.total()
Data structure style:
cart["items"].append(product)
total = calculate_cart_total(cart)
Both styles can be valid. The issue is consistency. A structure that exposes fields directly and also carries scattered business logic usually becomes awkward to evolve.
Common confusion / misconception
Objects are not automatically better than data structures. Data structures are fine for transport, serialization, and boundary crossings. The key is choosing the style that matches the job and not mixing them carelessly.
How to use it
Ask:
- Is this type mainly hiding decisions and enforcing behavior?
- Or is it mainly exposing data for other code to process?
- Am I creating a hybrid that leaks internals and still centralizes logic poorly?
Also watch for feature envy and Demeter violations, where code reaches through too many layers of another object.
Check yourself
Why can a hybrid type be harder to maintain than either a clean object or a plain data structure?
Mini drill or application
Pick one type in your code. Decide whether it is an object or a data structure. If it is acting like both, sketch one refactor direction: push behavior in, or pull behavior out.