Fork me on GitHub
#data-oriented-programming
<
2021-03-06
>
Yehonathan Sharvit19:03:31

A few thoughts and questions related to the value of “loose-coupling” between code and data: In Clojure, a customer namespace that manipulates a map that represents customer data is loosely coupled with customer data. While in Java, Customer class with a static methods that manipulate a Customer record (or an immutable data class) is strongly coupled with Customer.  One benefit of Clojure approach is that the namespace doesn’t have to “import” the class definition for Customer On the other hand, a Java developer might argue that the contract between code that manipulate Customer data and Customer data shape is not explicit  For instance, if you want to rename a field in Customer data, how would you discover all the pieced of code that need to be updated Rich likes to say: > We should program the insides of our sytems like we progam the outsides

Yehonathan Sharvit19:03:09

A Java developer might object: > Does it worth it to have code and data loosely coupled when they both live in the same program?

cgrand21:03:20

We don’t inherit data from our ancestor classes, we borrow it from the next application. 😉 More seriously data doesn’t live in the JVM most of the time. You just have representations of something external (either messages or some DB records).

Yehonathan Sharvit04:03:36

Let's compare what happens if we change the name of a data field that comes from outside. In classic Java, you'd have to change the class layout and some of its methods. Would it be simpler in DOP?

cgrand10:03:54

Changing names == breaking things. (That’s how you end with misspelt http headers.) Coping with a new field is more interesting: new protocol version, or db schema update. What do you do of this new field your app doesn’t care about (say you are filtering/routing events: you need to lug the field around you don’t need to model it)

Yehonathan Sharvit10:03:14

In classic java, does the code that implements filtering/routing events logic need to import class definitions for all types of events? I guess there are “design patterns” that make it possible to have different type of events with a common minimal set of fields to be processed by “generic” code.

cgrand10:03:43

It’s not about header vs payload

cgrand10:03:52

It’s about payload evolution

cgrand10:03:51

you dispatch purchase events based on amount

cgrand10:03:19

new version of the message comes in because of some new VAT regulation

cgrand10:03:25

you don’t care about the extra fields

cgrand10:03:32

but you need to pass them down

Yehonathan Sharvit11:03:05

How do they manage it in classic Java? They add the new fields to the Event class?

cgrand12:03:01

Either they go with a stratified approach (discrete typed getters + generic get — possibly generic gets, one for each type: getString, getLong etc.)

cgrand12:03:46

which allows to not break on payload extension (because backed by a map)

cgrand12:03:36

or they map each message piece as a class field and you get brittle code.

Yehonathan Sharvit13:03:08

What are discrete typed getters? Is it something like m.getAsString("price") ?

cgrand15:03:28

By discrete getters I mean getName getPrice and the like

cgrand15:03:48

GetAsString is a typed generic getter

Yehonathan Sharvit15:03:52

Are the terms “discrete getter” and “typed generic getter” well known terms?

cgrand21:03:20

We don’t inherit data from our ancestor classes, we borrow it from the next application. 😉 More seriously data doesn’t live in the JVM most of the time. You just have representations of something external (either messages or some DB records).

Yehonathan Sharvit04:03:36

Let's compare what happens if we change the name of a data field that comes from outside. In classic Java, you'd have to change the class layout and some of its methods. Would it be simpler in DOP?