4 ms·

Not all of us use a language that has classes or where it's considered good taste to use classes to structure everything.

ryeguy 14y ago
Using classes early on is just a technique to structure the data of your application. Even in a language without classes, you still have a way of representing your data that you could use. In C you would use structs, in a functional language you'd use a Type or whatever. You're mostly looking at a way to say "this entity belongs to this entity" and "this entity has many of this entity". That kind of thing. Classes or not, you still have a programming-level way of representing that. Even for languages that don't idiomatically have you use classes for everything, this is still where you would use them. If your language has classes, you should probably be using them for your entities and domain models. The place where you would use discretion by picking between classes or loose functions (like in python, php) is not the area you'd be sketching out in place of a database schema.
- snprbob86 14y ago
  > If your language has classes, you should probably be using them for your entities and domain models. Two years ago, I would have agreed with you. Now after some heavy, realistic usage of Clojure, I don't think I'll ever go back to modeling my domains with classes. Maps are just so much more flexible! Granted, you frequently have a "type" like key. In the ClojureScript compiler, for example, AST nodes look like {:op :if :test ... :then ...} You can say that the :op :if is a "type", but in reality, the type of that object is a Map. I'm working on a system now where there wasn't an obvious discriminated union or hierarchy of types. I fought the urge to introduce a type-like key in my map; the result has been quite pleasant.
  - kenko 14y ago
    The Clojure type of the object is a map, but for the AST-manipulating part of the compiler, isn't it in fact more accurate to say that the type of the object (the logical type, you might say, rather than the host type) is, in fact, `:if`? After some reasonable, realistic usage of Clojure, I'm quite glad of protocols and multimethods, which I have found make several complex things much easier to work through.
    - snprbob86 14y ago
      Paraphrasing: "Isn't the logical type, in fact, `:if`?" Yes. Clojure's types are, generally, of the solution domains. The primary solution domain being: computation. That's the domain that all of Clojure built in types belong to. The nature of Clojure and its community discourages the use of platform types for modeling the problem domain. Sometimes using platform types is desirable for optimizations like protocol dispatch and well-known structured fields. However, even when you're doing that, you're still operating in the solution domain. You're making an explicit decision about representation and evaluation: data structures and algorithms. However, any substantial application is going to need some custom code for inspecting and debugging values. You'll wind up designing some schema and writing some custom validation. There can be tools to help you with this: consider XML's (very ugly) XSD schema system. Or consider W3C validators for HTML and CSS. For an example in the OOP world, look at AstValidator.java in the Google Closure code base. You simply can't escape it. A rich, strong type system can give you a leg up and get you 70% of the way there, but it will actively fight you when you want to go the last mile. When and if you need it, you can basically make your own type system, tailored to your application.
      - mjw 14y ago
        > When and if you need it, you can basically make your own type system, tailored to your application. When you do decide you need to think about and enforce types though, it helps a lot to have a clean, well-thought-out formally-specified framework to do this in. I hear there's some work on an optional type system for Clojure which might help with this. Brings to mind the flip-side of that old chestnut about any sufficiently complicated C program containing an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. Any sufficiently complicated Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of a type system...
      - kenko 14y ago
        "When and if you need it, you can basically make your own type system, tailored to your application." Only given an exiguous understanding of what a type system is. Maybe if Typed Clojure gets to the state of Typed Racket, sure, you could do that. But at the moment lots of things that would be statically discoverable in a language like Haskell---where, too, the types are of the solution domains---will pop up, to your woe, at runtime, in Clojure. This can be mitigated with some minor macrology and some major discipline, but the Typed Clojure route is major, major macrology (and not just macrology, obviously).
- codewright 14y ago
  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

Using classes early on is just a technique to structure the data of your application. Even in a language without classes, you still have a way of representing your data that you could use. In C you would use structs, in a functional language you'd use a Type or whatever. You're mostly looking at a way to say "this entity belongs to this entity" and "this entity has many of this entity". That kind of thing. Classes or not, you still have a programming-level way of representing that. Even for languages that don't idiomatically have you use classes for everything, this is still where you would use them. If your language has classes, you should probably be using them for your entities and domain models. The place where you would use discretion by picking between classes or loose functions (like in python, php) is not the area you'd be sketching out in place of a database schema.

snprbob86 14y ago
> If your language has classes, you should probably be using them for your entities and domain models. Two years ago, I would have agreed with you. Now after some heavy, realistic usage of Clojure, I don't think I'll ever go back to modeling my domains with classes. Maps are just so much more flexible! Granted, you frequently have a "type" like key. In the ClojureScript compiler, for example, AST nodes look like {:op :if :test ... :then ...} You can say that the :op :if is a "type", but in reality, the type of that object is a Map. I'm working on a system now where there wasn't an obvious discriminated union or hierarchy of types. I fought the urge to introduce a type-like key in my map; the result has been quite pleasant.
- kenko 14y ago
  The Clojure type of the object is a map, but for the AST-manipulating part of the compiler, isn't it in fact more accurate to say that the type of the object (the logical type, you might say, rather than the host type) is, in fact, `:if`? After some reasonable, realistic usage of Clojure, I'm quite glad of protocols and multimethods, which I have found make several complex things much easier to work through.
  - snprbob86 14y ago
    Paraphrasing: "Isn't the logical type, in fact, `:if`?" Yes. Clojure's types are, generally, of the solution domains. The primary solution domain being: computation. That's the domain that all of Clojure built in types belong to. The nature of Clojure and its community discourages the use of platform types for modeling the problem domain. Sometimes using platform types is desirable for optimizations like protocol dispatch and well-known structured fields. However, even when you're doing that, you're still operating in the solution domain. You're making an explicit decision about representation and evaluation: data structures and algorithms. However, any substantial application is going to need some custom code for inspecting and debugging values. You'll wind up designing some schema and writing some custom validation. There can be tools to help you with this: consider XML's (very ugly) XSD schema system. Or consider W3C validators for HTML and CSS. For an example in the OOP world, look at AstValidator.java in the Google Closure code base. You simply can't escape it. A rich, strong type system can give you a leg up and get you 70% of the way there, but it will actively fight you when you want to go the last mile. When and if you need it, you can basically make your own type system, tailored to your application.
    - mjw 14y ago
      > When and if you need it, you can basically make your own type system, tailored to your application. When you do decide you need to think about and enforce types though, it helps a lot to have a clean, well-thought-out formally-specified framework to do this in. I hear there's some work on an optional type system for Clojure which might help with this. Brings to mind the flip-side of that old chestnut about any sufficiently complicated C program containing an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. Any sufficiently complicated Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of a type system...
    - kenko 14y ago
      "When and if you need it, you can basically make your own type system, tailored to your application." Only given an exiguous understanding of what a type system is. Maybe if Typed Clojure gets to the state of Typed Racket, sure, you could do that. But at the moment lots of things that would be statically discoverable in a language like Haskell---where, too, the types are of the solution domains---will pop up, to your woe, at runtime, in Clojure. This can be mitigated with some minor macrology and some major discipline, but the Typed Clojure route is major, major macrology (and not just macrology, obviously).
codewright 14y ago
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]