6 ms·

I'm a Clojure user like snprbob86. A C struct is just data, a map is just data. You're using the term classes when you mean data or data structures. Classes a

I'm a Clojure user like snprbob86. A C struct is just data, a map is just data. You're using the term classes when you mean data or data structures. Classes are the the creation of complexity by unnecessarily fusing code with data. If you don't mean classes specifically, then use the universal terms "data structure" or "schema". > If your language has classes, you should probably be using them for your entities and domain models. Not necessarily at all. It takes a profound lack of imagination to believe that's the only way to handle business logic ++ persistence. Furthermore, freeing yourself from the constraints of the persistence side (presumed to be a SQL DB in this conversation) in the initial sketch/mock stage is foolishness beyond measurement.

ryeguy 14y ago
> Not necessarily at all. It takes a profound lack of imagination to believe that's the only way to handle business logic ++ persistence. It is a stretch to say that there is an idiomatic way to avoid classes as domain objects in most languages. Imagine in $classBasedLanguage you used static functions and key/value arrays..do you think that's a good idea? That's all I was saying. > Furthermore, freeing yourself from the constraints of the persistence side.. If you're making an ERD, a lot of what you're doing is deciding entity relationships and just naming your data. None of that is impossible with classes.
Hermel 14y ago
> Classes are the the creation of complexity by unnecessarily fusing code with data. No, classes discourage unnecessary complexity by fusing code with data -- leading to a better separation of concerns. In the end, the question is about how to split up a software into components. Should "data" and "business logic" be separate modules or shouldn't it rather be (for example) "accounting" and "hr"?
- jfb 14y ago
  In other words, classes are a namespacing mechanism.
- deleted 14y ago
  [deleted]

ryeguy 14y ago

> Not necessarily at all. It takes a profound lack of imagination to believe that's the only way to handle business logic ++ persistence. It is a stretch to say that there is an idiomatic way to avoid classes as domain objects in most languages. Imagine in $classBasedLanguage you used static functions and key/value arrays..do you think that's a good idea? That's all I was saying. > Furthermore, freeing yourself from the constraints of the persistence side.. If you're making an ERD, a lot of what you're doing is deciding entity relationships and just naming your data. None of that is impossible with classes.

Hermel 14y ago

> Classes are the the creation of complexity by unnecessarily fusing code with data. No, classes discourage unnecessary complexity by fusing code with data -- leading to a better separation of concerns. In the end, the question is about how to split up a software into components. Should "data" and "business logic" be separate modules or shouldn't it rather be (for example) "accounting" and "hr"?

jfb 14y ago
In other words, classes are a namespacing mechanism.
deleted 14y ago
[deleted]