|
|
|
|
|
|
by cam-
3928 days ago
|
|
|
In real world business logic and modeling you have to work really hard to make it fit into an OO paradigm. It also gets hard to manage long term as your data structures kind of get stuck with all the restrictions that OO allows you to make. Javascript object literals are fantastic as they make data transfer objects simple, fast and not polluted by business logic. Once you get used to passing around DTOs that way then a functional style of programming becomes more useful. For the most part programming is getting data from one domain data model and then converting to another domain data model, OO doesn't really help there, and if anything is a hindrance. Unfortunately software engineers love to abstract to the nth degree so sometimes you get stuck with tight OO models of DTOs and transformation layers. |
|
|
It has always been an unfortunate characteristic of using classes for application domain information that it resulted in information being hidden behind class-specific micro-languages, e.g. even the seemingly harmless employee.getName() is a custom interface to data. Putting information in such classes is a problem, much like having every book being written in a different language would be a problem. You can no longer take a generic approach to information processing. This results in an explosion of needless specificity, and a dearth of reuse.
This is why Clojure has always encouraged putting such information in maps, and that advice doesn't change with datatypes. By using defrecord you get generically manipulable information, plus the added benefits of type-driven polymorphism, and the structural efficiencies of fields. OTOH, it makes no sense for a datatype that defines a collection like vector to have a default implementation of map, thus deftype is suitable for defining such programming constructs.