3 ms·
In most OOP scenarios one would model an application domain concept as a class, but then you get bogged down in implementing all sorts of minutiae that really h
by joubert 16y ago
In most OOP scenarios one would model an application domain concept as a class, but then you get bogged down in implementing all sorts of minutiae that really have nothing to do in describing the model (e.g. getters/setters, initialization, etc.)
Clojure, for one, encourages the distinction between data structures that represent the programming domain, and data structures that represent the application domain.
There's defrecord, which goes a little further than record structures in other languages, in that it also gives the benefit of type-driven polymorphism.
- silentbicycle 16y agoClasses aren't necessary* for OO. Inheritance isn't necessary, either (and probably causes as many problems as it fixes). Late-binding via message-passing pretty much covers it, IMHO. Structure code as a group of autonomous actors communicating by passing messages according to agreed-upon protocols, and each (polymorphically) chooses how to react to them. Erlang implements that model with unusual clarity, IMHO. * Neither are prototypes.