4 ms·

Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers, which ends up look

by mc808 12y ago

Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers, which ends up looking like old-fashioned procedural code coated with a sugary OOP shell. Encapsulation and inheritance and stateful objects have their place, but the "object" metaphor can really lead down the wrong path when taken too literally (as it is in practically every course that starts with "animal" or "shape" or "car" examples).

k__ 12y ago
If I don't explicitly need "state" (user-data in models or GUI-state in view-models) I leave it out. Most of the time I use classes and their objects as a stateless bag of related methods. Like namespaces...
- chriswarbo 12y ago
  IMHO classes are a "jack of all trades, master of none". They're sort of like namespaces, a bit like modules, kind of like closures, somewhat like types, almost like first-class functions, etc. On a somewhat related note, http://www.newspeaklanguage.org http://www.newspeaklanguage.org uses classes for all kinds of things, including namespaces.
  - k__ 12y ago
    lol, yes. But I have to admit, the dynamic properties of objects make them much more versatile than namespaces or modules. If I would use them only as namespaces, by defining every of my (stateless) methods static, they would work exactly as a namespace. But when they're bound to an object instead, I can switch out implementation details easily when needed. So I would consider classes and their objects to be a more powerful version of namespaces.
zak_mc_kracken 12y ago
> Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers, These are not mutually exclusive.
haberman 12y ago
Could not agree more. I've heard of interviewers who say to candidates: "I have a bookshelf. Design me an OO interface." They want the candidate to create objects for Shelf, Book, etc. without knowing anything at all about what the software system is supposed to do! This is so backwards IMO that I cringe just to tell this story.
- liveoneggs 12y ago
  I was asked to whiteboard the object model of this exact question.
- empthought 12y ago
  The intent of that type of question is to see what questions the candidate asks in order to elucidate an appropriate design. That being said, I can easily imagine it being misused by bad interviewers.
graycat 12y ago
Yup. <rant> YMMV Early in the OOP fad phase, the suggestion that OOP had any very close connection with real world objects and the idea described in the OP as anthropomorphism sent me into nearly a rage of indignation -- as if I was being force fed conceptual sewage. E.g., consider plants, billiard balls, cars, bottles in a cupboard, etc. with each represented by a software object (that is, an instance of some class) and then want to program some real world situation for those real world, physical objects, say, the first shot in a game of billiards where the balls bounce off each other and the rails and fall into pockets, where planets affect each other via gravity or collide, where cars move as in traffic, etc.; then, we ask, do the programming constructs of OOP really, naturally, automatically, or even seriously help handling the billiard ball collisions, the gravity, the traffic jams? My view was -- not really, at best not much. Eventually I just decided to regard OOP as a glass half full and like what was there that I could like and f'get about the rest; then I regarded an instance of a class as much like what the OP calls a record or, more accurately, like a structure in PL/I. Note: PL/I structures have a really nice advantage because all the addressing is just array addressing -- super nice, that is, simple and fast, that is, typically there is little or no need for the compiled code to follow pointers to get to variables in the structure. Then the definition of the class was much like a based structure in PL/I where could allocate as many instances as desired. Then for the OOP methods, in PL/I just have some entry variables in the structure. The rest of OOP looked like no more than syntactic convenience (sugar). Actually, for OOP inheritance, PL/I had key word LIKE where could have a structure A and then define a structure B and for part of B say it was just like structure A. For OOP inheritance and polymorphism, I was not impressed: So far, in my own code, I've never used inheritance if only because there will be source code dependencies likely a long way away in the code base -- e.g., might be inheriting from some class have never seen, which sounds like programming partly in the dark and risky, that is, error prone. For polymorphism, I've used it a few times -- okay, I did it with interfaces which are essentially the same as passing an entry variable in old Fortran. For encapsulation, sure, I get some of that when I use some of the classes in the Microsoft .NET Framework; if I can trust what Microsoft did, and really I have little choice, then okay. I have written a few classes where there is some encapsulation -- push the low level details out of sight where I don't have to work with them or risk using them wrong and making a mistake. E.g., have a class that reads a file and has a method that on each call returns the next token in the file -- not a biggie. Two final points: (1) Simplicity. Mostly just keep everything as simple as possible but not simpler. If something is at all complicated, then write some good documentation to explain it and show that, still, actually, it really is simple. With things so simple, a lot of the tricky stuff in this and that programming language mostly don't much need. E.g., a closure sounds a lot like passing to a function A an entry variable as an argument to a function B and where function B uses some syntactically nested scope of names to manipulate variables it has access to merely via scope of names and where the function A does not. I did that a few times in PL/I; it's tricky coding, and I'm not thrilled with it. (2) Libraries. The code I write is mostly just mortar or glue to hold together uses of functions and methods in classes from Microsoft, etc. In my project, at times I've written some code that has some real conceptual content, really from some applied math I derived, but such code has been relatively short (the code via Microsoft's ASP.NET for even a relatively simple Web page can be much longer), and given the applied math in good form, the code was fast, fun, easy, and short. So, I write some challenging code occasionally, but otherwise I end up writing a lot of routine mortar or glue code. So, for me, the programming comes down to define storage (sometimes with classes), allocate/free (with the Microsoft managed code languages mostly can just f'get about free), assign the value of an expression, if-then-else, do-while, call-return, try-catch, and then document it so that six months later I can still understand it. Right, the OOP examples with animals, shapes, and cars I did not regard as significantly useful or helpful in practice -- much better is just document the code, that is, explain it to a human. </rant> YMMV
Retra 12y ago
I read a Java textbook that started with something like "OO allows you to model things like they are in reality. A dog has a tail, and it can be wagging or not. A dog has a name..." But dogs don't 'have names' in the OO sense. Humans have names for dogs. We can give a dog two names and it doesn't matter whether other dogs have two names or not. We can have a dog with no name, yet we can still call it by something as though it were a name. We can talk about the name of a dog that doesn't even exist. OO is a valuable methodology, but you shouldn't have to lie to yourself to see that. It's a convenient way to bundle certain concepts together, and many problems do not require -- or are actively hindered -- by that bundling.
- greenleafjacob 12y ago
  Well names are a bit of a bad example. Entire fields of study were spawned from that example [1]. A better example might be a credit card, which always has a number and a cardholder. Things get interesting when you might formalize: * Expiration (do all credit cards expire? Is expiration necessarily a date, or is it a predicate?) * Cardholder - referent might be another entity in your system * Is the card number encrypted? How do you represent encryption? [1]: https://en.wikipedia.org/wiki/On_Denoting https://en.wikipedia.org/wiki/On_Denoting
  - Retra 12y ago
    These kind of issues lead to the development of aspect-oriented programming, which is an attempt to better match our intuition about how things in reality behave in a compositional manner.

by mc808 12y ago

k__ 12y ago

If I don't explicitly need "state" (user-data in models or GUI-state in view-models) I leave it out. Most of the time I use classes and their objects as a stateless bag of related methods. Like namespaces...

chriswarbo 12y ago
IMHO classes are a "jack of all trades, master of none". They're sort of like namespaces, a bit like modules, kind of like closures, somewhat like types, almost like first-class functions, etc. On a somewhat related note, http://www.newspeaklanguage.org http://www.newspeaklanguage.org uses classes for all kinds of things, including namespaces.
- k__ 12y ago
  lol, yes. But I have to admit, the dynamic properties of objects make them much more versatile than namespaces or modules. If I would use them only as namespaces, by defining every of my (stateless) methods static, they would work exactly as a namespace. But when they're bound to an object instead, I can switch out implementation details easily when needed. So I would consider classes and their objects to be a more powerful version of namespaces.

zak_mc_kracken 12y ago

> Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers, These are not mutually exclusive.

haberman 12y ago

Could not agree more. I've heard of interviewers who say to candidates: "I have a bookshelf. Design me an OO interface." They want the candidate to create objects for Shelf, Book, etc. without knowing anything at all about what the software system is supposed to do! This is so backwards IMO that I cringe just to tell this story.

liveoneggs 12y ago
I was asked to whiteboard the object model of this exact question.
empthought 12y ago
The intent of that type of question is to see what questions the candidate asks in order to elucidate an appropriate design. That being said, I can easily imagine it being misused by bad interviewers.

graycat 12y ago

Yup. <rant> YMMV Early in the OOP fad phase, the suggestion that OOP had any very close connection with real world objects and the idea described in the OP as anthropomorphism sent me into nearly a rage of indignation -- as if I was being force fed conceptual sewage. E.g., consider plants, billiard balls, cars, bottles in a cupboard, etc. with each represented by a software object (that is, an instance of some class) and then want to program some real world situation for those real world, physical objects, say, the first shot in a game of billiards where the balls bounce off each other and the rails and fall into pockets, where planets affect each other via gravity or collide, where cars move as in traffic, etc.; then, we ask, do the programming constructs of OOP really, naturally, automatically, or even seriously help handling the billiard ball collisions, the gravity, the traffic jams? My view was -- not really, at best not much. Eventually I just decided to regard OOP as a glass half full and like what was there that I could like and f'get about the rest; then I regarded an instance of a class as much like what the OP calls a record or, more accurately, like a structure in PL/I. Note: PL/I structures have a really nice advantage because all the addressing is just array addressing -- super nice, that is, simple and fast, that is, typically there is little or no need for the compiled code to follow pointers to get to variables in the structure. Then the definition of the class was much like a based structure in PL/I where could allocate as many instances as desired. Then for the OOP methods, in PL/I just have some entry variables in the structure. The rest of OOP looked like no more than syntactic convenience (sugar). Actually, for OOP inheritance, PL/I had key word LIKE where could have a structure A and then define a structure B and for part of B say it was just like structure A. For OOP inheritance and polymorphism, I was not impressed: So far, in my own code, I've never used inheritance if only because there will be source code dependencies likely a long way away in the code base -- e.g., might be inheriting from some class have never seen, which sounds like programming partly in the dark and risky, that is, error prone. For polymorphism, I've used it a few times -- okay, I did it with interfaces which are essentially the same as passing an entry variable in old Fortran. For encapsulation, sure, I get some of that when I use some of the classes in the Microsoft .NET Framework; if I can trust what Microsoft did, and really I have little choice, then okay. I have written a few classes where there is some encapsulation -- push the low level details out of sight where I don't have to work with them or risk using them wrong and making a mistake. E.g., have a class that reads a file and has a method that on each call returns the next token in the file -- not a biggie. Two final points: (1) Simplicity. Mostly just keep everything as simple as possible but not simpler. If something is at all complicated, then write some good documentation to explain it and show that, still, actually, it really is simple. With things so simple, a lot of the tricky stuff in this and that programming language mostly don't much need. E.g., a closure sounds a lot like passing to a function A an entry variable as an argument to a function B and where function B uses some syntactically nested scope of names to manipulate variables it has access to merely via scope of names and where the function A does not. I did that a few times in PL/I; it's tricky coding, and I'm not thrilled with it. (2) Libraries. The code I write is mostly just mortar or glue to hold together uses of functions and methods in classes from Microsoft, etc. In my project, at times I've written some code that has some real conceptual content, really from some applied math I derived, but such code has been relatively short (the code via Microsoft's ASP.NET for even a relatively simple Web page can be much longer), and given the applied math in good form, the code was fast, fun, easy, and short. So, I write some challenging code occasionally, but otherwise I end up writing a lot of routine mortar or glue code. So, for me, the programming comes down to define storage (sometimes with classes), allocate/free (with the Microsoft managed code languages mostly can just f'get about free), assign the value of an expression, if-then-else, do-while, call-return, try-catch, and then document it so that six months later I can still understand it. Right, the OOP examples with animals, shapes, and cars I did not regard as significantly useful or helpful in practice -- much better is just document the code, that is, explain it to a human. </rant> YMMV

Retra 12y ago

I read a Java textbook that started with something like "OO allows you to model things like they are in reality. A dog has a tail, and it can be wagging or not. A dog has a name..." But dogs don't 'have names' in the OO sense. Humans have names for dogs. We can give a dog two names and it doesn't matter whether other dogs have two names or not. We can have a dog with no name, yet we can still call it by something as though it were a name. We can talk about the name of a dog that doesn't even exist. OO is a valuable methodology, but you shouldn't have to lie to yourself to see that. It's a convenient way to bundle certain concepts together, and many problems do not require -- or are actively hindered -- by that bundling.

greenleafjacob 12y ago
Well names are a bit of a bad example. Entire fields of study were spawned from that example [1]. A better example might be a credit card, which always has a number and a cardholder. Things get interesting when you might formalize: * Expiration (do all credit cards expire? Is expiration necessarily a date, or is it a predicate?) * Cardholder - referent might be another entity in your system * Is the card number encrypted? How do you represent encryption? [1]: https://en.wikipedia.org/wiki/On_Denoting https://en.wikipedia.org/wiki/On_Denoting
- Retra 12y ago
  These kind of issues lead to the development of aspect-oriented programming, which is an attempt to better match our intuition about how things in reality behave in a compositional manner.