4 ms·

This is the original concept of object-oriented programming, i.e. don't ask for information, pass a message instead and let the destination object do its job.

This is the original concept of object-oriented programming, i.e. don't ask for information, pass a message instead and let the destination object do its job. Ultimately, this doesn't really work, because it increases coupling. In order to decrease coupling, the functionality that is hidden behind a message should be factored out into another class, and thus we end up with classes that are actually simple conditional functions with embedded arguments. So, a better strategy would be to simply have functions that accept a number of parameters and do the job we want. For example, a function that sends a package, like the one in the article, should accept a number of parameters, check upon those parameters and select the appropriate action to perform. In this case, we wouldn't care about nulls, because they would be handled gracefully by our function, plus we get decoupling and increased reusability for free.

bitwize 8y ago
It worked in the early days of Smalltalk, because a Smalltalk environment is basically a blob of tightly coupled classes that all call and delegate to one another, up and down the abstraction chain, and when you want to load the application you just snarf all those classes into memory, all at once. These days, if you're a good little do-bee, you will properly use the SOLID principles and introduce interfaces everywhere there's an identifiable joint between classes. Instead of having a class call into another class, you change the reference of the class's object to an interface reference and call through that. So now you've introduced more code, more concepts, and more complexity to do something like send a fucking email which is conceptually simple on paper (and you have a library to handle actually sending the email). Congratulations. Welcome to software-architecture NASA.
- chriswarbo 8y ago
  > a Smalltalk environment is basically a blob of tightly coupled classes that all call and delegate to one another, up and down the abstraction chain, and when you want to load the application you just snarf all those classes into memory, all at once. I really like the idea of Smalltalk images (which can also be used by some Lisps, and Factor IIRC) since we can tweak and fix values directly, rather than trying to orchestrate a way for the fixed value to be used the next time we restart it. On the other hand, I really like functional programming ideas like immutability (which naively would stop us fixing/tweaking things) and referential transparency (where an expression and its result are interchangable; if we switch out the result, it's no longer interchangable with the expression we wrote). I also like version control, reproducible builds, etc. which seem to be trickier with images. An interesting research area, I suppose :) > So now you've introduced more code, more concepts, and more complexity to do something like send a fucking email which is conceptually simple on paper (and you have a library to handle actually sending the email). I completely agree w.r.t. the insanity of people decoupling all of their classes from each other (my old boss got infected by that idea, it was painful). Still, the particular example of sending an email is a legitimate case of external interaction: whilst it's fine to, for example, create as many Customer/Request/whatever objects as we like during unit tests (since they're internal implementation details) we don't want those tests to be sending actual emails. So if I were writing this, I would have the email-sending-mechanism as a parameter, where we can pass a real email sender when running on production and a dummy argument-swallowing black hole during tests. Note that the interface for an email sender is simply a function (from EmailDetails or whatever, to void). > Congratulations. Welcome to software-architecture NASA. One thing I've found about architecture astronauts is that they obsess over "reusability", yet insist on creating all their own stuff from scratch, rather than reusing what's already provided by the language. For example, from this article: public interface CommunicationMethod { void send(CustomerServiceAnnouncement announcement); } The author has just re-invented the idea of a function! Yet (as Rich Hickey famously said), by inventing a new class they've made themselves incompatible/unusable by all the existing code, infrastructure and tooling that works for functions(/closures/whatever).

bitwize 8y ago

It worked in the early days of Smalltalk, because a Smalltalk environment is basically a blob of tightly coupled classes that all call and delegate to one another, up and down the abstraction chain, and when you want to load the application you just snarf all those classes into memory, all at once. These days, if you're a good little do-bee, you will properly use the SOLID principles and introduce interfaces everywhere there's an identifiable joint between classes. Instead of having a class call into another class, you change the reference of the class's object to an interface reference and call through that. So now you've introduced more code, more concepts, and more complexity to do something like send a fucking email which is conceptually simple on paper (and you have a library to handle actually sending the email). Congratulations. Welcome to software-architecture NASA.

chriswarbo 8y ago
> a Smalltalk environment is basically a blob of tightly coupled classes that all call and delegate to one another, up and down the abstraction chain, and when you want to load the application you just snarf all those classes into memory, all at once. I really like the idea of Smalltalk images (which can also be used by some Lisps, and Factor IIRC) since we can tweak and fix values directly, rather than trying to orchestrate a way for the fixed value to be used the next time we restart it. On the other hand, I really like functional programming ideas like immutability (which naively would stop us fixing/tweaking things) and referential transparency (where an expression and its result are interchangable; if we switch out the result, it's no longer interchangable with the expression we wrote). I also like version control, reproducible builds, etc. which seem to be trickier with images. An interesting research area, I suppose :) > So now you've introduced more code, more concepts, and more complexity to do something like send a fucking email which is conceptually simple on paper (and you have a library to handle actually sending the email). I completely agree w.r.t. the insanity of people decoupling all of their classes from each other (my old boss got infected by that idea, it was painful). Still, the particular example of sending an email is a legitimate case of external interaction: whilst it's fine to, for example, create as many Customer/Request/whatever objects as we like during unit tests (since they're internal implementation details) we don't want those tests to be sending actual emails. So if I were writing this, I would have the email-sending-mechanism as a parameter, where we can pass a real email sender when running on production and a dummy argument-swallowing black hole during tests. Note that the interface for an email sender is simply a function (from EmailDetails or whatever, to void). > Congratulations. Welcome to software-architecture NASA. One thing I've found about architecture astronauts is that they obsess over "reusability", yet insist on creating all their own stuff from scratch, rather than reusing what's already provided by the language. For example, from this article: public interface CommunicationMethod { void send(CustomerServiceAnnouncement announcement); } The author has just re-invented the idea of a function! Yet (as Rich Hickey famously said), by inventing a new class they've made themselves incompatible/unusable by all the existing code, infrastructure and tooling that works for functions(/closures/whatever).