data-oriented-programming

Spread the word among the global developer community about Data-Oriented programming https://en.wikipedia.org/wiki/Draft:Data-oriented_programming
Yehonathan Sharvit 2021-03-06T19:43:31.057Z

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 Sharvit 2021-03-06T19:45:09.058500Z

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

cgrand 2021-03-08T10:19:54.071400Z

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 Sharvit 2021-03-08T10:52:14.072600Z

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.

cgrand 2021-03-08T10:53:43.072900Z

It’s not about header vs payload

cgrand 2021-03-08T10:53:52.073100Z

It’s about payload evolution

cgrand 2021-03-08T10:55:51.073300Z

you dispatch purchase events based on amount

cgrand 2021-03-08T10:56:19.073500Z

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

cgrand 2021-03-08T10:56:25.073700Z

you don’t care about the extra fields

cgrand 2021-03-08T10:56:32.073900Z

but you need to pass them down

Yehonathan Sharvit 2021-03-08T11:04:05.074100Z

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

cgrand 2021-03-08T12:55:01.074900Z

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

cgrand 2021-03-08T12:55:46.075100Z

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

cgrand 2021-03-08T12:57:36.075300Z

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

Yehonathan Sharvit 2021-03-08T13:06:08.075500Z

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

cgrand 2021-03-08T15:05:28.077100Z

By discrete getters I mean getName getPrice and the like

cgrand 2021-03-08T15:05:48.077800Z

GetAsString is a typed generic getter

Yehonathan Sharvit 2021-03-08T15:29:52.078Z

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

cgrand 2021-03-08T19:53:14.078400Z

Nope