6 ms·

I am using a more data oriented approach [1],even if I mainly work with C# which is an object oriented language. I use inheritance scarcely and I do not use en

I am using a more data oriented approach [1],even if I mainly work with C# which is an object oriented language. I use inheritance scarcely and I do not use encapsulation. I separate the code from the data. I have data classes and code classes which do not hold state, and I treat those code classes similarly to modules in other languages. Now I don't even need classes to hold the data since the introduction of records which are immutable containers of data. [1] https://www.manning.com/books/data-oriented-programming https://www.manning.com/books/data-oriented-programming

pharmakom 4y ago
Sounds like you are writing C# in F# style.
spinningslate 4y ago
Interesting. Can you expand on how this is similar to/different from a functional approach? i.e. using types & values to define and hold data respectively, and functions to define the logic/transformations that apply among types.
- codethief 4y ago
  To me this sounds very much like functional programming as well despite the fact that in OP's link it is said that > Distinguish data-oriented programming from functional and OO programming I mean, if code & data are separate and there is no state, there's no other option left in the code separation vs. stateless/stateful (<> mutations) 2×2 matrix other than functional programming. The 2×2=4 options are: procedural (data and code separate, mutations allowed), object-oriented (data and code not separate, mutations allowed), functional (data and code separate, no mutations/state), and a fourth option (data and code not separate (i.e. still classes), but no mutations/state) which Gary Bernhardt jokingly calls FauxO, see minutes 10:21-13:31 of his talk about Boundaries: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
  - spinningslate 4y ago
    > To me this sounds very much like functional programming as well despite the fact that in OP's link it is said that >> Distinguish data-oriented programming from functional and OO programming Yes, that was the basis of my question. The book description also states: > In DOP, you maintain application data in persistent generic data structures separated from the program’s code. You use general-purpose functions to manipulate the data without mutating it. Which seems a lot like functional programming. The use of 'persistent' is perhaps interesting, though there's nothing inherent in FP that excludes persistence obviously.
Tainnor 4y ago
IMHO, encapsulation is a principle that can also be applied to non-traditional OOP or even FP, even when there is no mutable state. It's mostly about limiting the knowledge that certain parts of the program need to have about the internals of certain other parts of the program. For example, if I want to use Redis as a cache, I can make sure to only do so via a specific set of functions and data structures from a particular class/module/... that don't expose any lower-level details.
- daxfohl 4y ago
  Agreed. Having worked in F# for a few years, I still find encapsulation extremely useful for things like the logging problem discussed in the article. (Another advantage is the ability to specify configurations via IoC frameworks or bespoke options).
- agumonkey 4y ago
  Indeed, encapsulation is probably better referred to a minimal coupling. Near zero knowledge interaction. It's a variability principle.
tasubotadas 4y ago
Sounds like an anemic domain model. OOP is orthogonal concept to data-driven programming.
- vinceguidry 4y ago
  Objects are a marriage of logic and data. You can certainly implement a data-driven system design on top of an object oriented language, but you pretty much have to just make your classes into simple data repositories, and not take advantage of the main aspect that makes OOP interesting, dynamic dispatch. Most of my coding is done in Ruby, and when I'm doing data processing stuff, I don't bother making any classes. I break out the class keyword when my workflow stops resembling a pipeline, when I'm grabbing all kinds of info from different places and I don't always know how I'm going to be using it. This moves it away from a data approach and more towards a, well, object approach rather than a data approach. Where the behavior of the program is dependent on the metadata just as much as the data.
zasdffaa 4y ago
> and I do not use encapsulation works well for small stuff you can keep in your head, don't know how well that will scale :) > I use inheritance scarcely and I do not use encapsulation. I separate the code from the data "It looks like you are writing Pascal. Would you like some help with that?" > Now I don't even need classes to hold the data since the introduction of records which are immutable containers of data. Uh, how is a record not just a class with a few nice properties such as immutability, which, BTW you can have in C# anyway albeit with some extra boilerplate (annotating every class property with 'readonly' (i think it is) means it can only be set in the ctor. I'm not sure what to make of your post. Perhaps I should read the book.
rTX5CMRXIfFG 4y ago
Could you expound on why you don’t use encapsulation? I get the criticism against inheritance but encapsulation seems like good practice—it’s systematically making it impossible to introduce bugs by disallowing clients of the code to see and misuse details that they should not be seeing/misusing.
- kasey_junk 4y ago
  Not the OP but typically what people mean when they say they don’t use encapsulation is that they don’t use it to hide state, but they will still use accessibility modifiers to limit the scope of an api. If your state is all largely records or stdlib datastructures that you are passing to functions that only operate on state passed to them, then hidden state is just a complexity without much value.
tyleo 4y ago
Incredible, your views are very close to my own. I slightly disagree on encapsulation in that my view is more like, “don’t let it get in the way”. I think this view on encapsulation makes much more sense from the data-oriented side though.
bob1029 4y ago
Data-oriented is the way to go IMO. I am using the latest version of C# and our current domain models use zero inheritance. We also do not allow for any sort of complex type nesting so composition is also constrained. In order to relate complex types together, foreign key properties and dedicated relation types are used. Every domain type we have can be mapped to & from a relational table without any difficulty. This is important because we use SQL for certain parts of the product. Turns out this kind of compatibility has tons of other benefits that you may find value in (we certainly did).
daxfohl 4y ago
How does this apply to problems like filters and emitters for logging as discussed in the article?

pharmakom 4y ago

Sounds like you are writing C# in F# style.

spinningslate 4y ago

Interesting. Can you expand on how this is similar to/different from a functional approach? i.e. using types & values to define and hold data respectively, and functions to define the logic/transformations that apply among types.

codethief 4y ago
To me this sounds very much like functional programming as well despite the fact that in OP's link it is said that > Distinguish data-oriented programming from functional and OO programming I mean, if code & data are separate and there is no state, there's no other option left in the code separation vs. stateless/stateful (<> mutations) 2×2 matrix other than functional programming. The 2×2=4 options are: procedural (data and code separate, mutations allowed), object-oriented (data and code not separate, mutations allowed), functional (data and code separate, no mutations/state), and a fourth option (data and code not separate (i.e. still classes), but no mutations/state) which Gary Bernhardt jokingly calls FauxO, see minutes 10:21-13:31 of his talk about Boundaries: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
- spinningslate 4y ago
  > To me this sounds very much like functional programming as well despite the fact that in OP's link it is said that >> Distinguish data-oriented programming from functional and OO programming Yes, that was the basis of my question. The book description also states: > In DOP, you maintain application data in persistent generic data structures separated from the program’s code. You use general-purpose functions to manipulate the data without mutating it. Which seems a lot like functional programming. The use of 'persistent' is perhaps interesting, though there's nothing inherent in FP that excludes persistence obviously.

Tainnor 4y ago

IMHO, encapsulation is a principle that can also be applied to non-traditional OOP or even FP, even when there is no mutable state. It's mostly about limiting the knowledge that certain parts of the program need to have about the internals of certain other parts of the program. For example, if I want to use Redis as a cache, I can make sure to only do so via a specific set of functions and data structures from a particular class/module/... that don't expose any lower-level details.

daxfohl 4y ago
Agreed. Having worked in F# for a few years, I still find encapsulation extremely useful for things like the logging problem discussed in the article. (Another advantage is the ability to specify configurations via IoC frameworks or bespoke options).
agumonkey 4y ago
Indeed, encapsulation is probably better referred to a minimal coupling. Near zero knowledge interaction. It's a variability principle.

tasubotadas 4y ago

Sounds like an anemic domain model. OOP is orthogonal concept to data-driven programming.

vinceguidry 4y ago
Objects are a marriage of logic and data. You can certainly implement a data-driven system design on top of an object oriented language, but you pretty much have to just make your classes into simple data repositories, and not take advantage of the main aspect that makes OOP interesting, dynamic dispatch. Most of my coding is done in Ruby, and when I'm doing data processing stuff, I don't bother making any classes. I break out the class keyword when my workflow stops resembling a pipeline, when I'm grabbing all kinds of info from different places and I don't always know how I'm going to be using it. This moves it away from a data approach and more towards a, well, object approach rather than a data approach. Where the behavior of the program is dependent on the metadata just as much as the data.

zasdffaa 4y ago

> and I do not use encapsulation works well for small stuff you can keep in your head, don't know how well that will scale :) > I use inheritance scarcely and I do not use encapsulation. I separate the code from the data "It looks like you are writing Pascal. Would you like some help with that?" > Now I don't even need classes to hold the data since the introduction of records which are immutable containers of data. Uh, how is a record not just a class with a few nice properties such as immutability, which, BTW you can have in C# anyway albeit with some extra boilerplate (annotating every class property with 'readonly' (i think it is) means it can only be set in the ctor. I'm not sure what to make of your post. Perhaps I should read the book.

rTX5CMRXIfFG 4y ago

Could you expound on why you don’t use encapsulation? I get the criticism against inheritance but encapsulation seems like good practice—it’s systematically making it impossible to introduce bugs by disallowing clients of the code to see and misuse details that they should not be seeing/misusing.

kasey_junk 4y ago
Not the OP but typically what people mean when they say they don’t use encapsulation is that they don’t use it to hide state, but they will still use accessibility modifiers to limit the scope of an api. If your state is all largely records or stdlib datastructures that you are passing to functions that only operate on state passed to them, then hidden state is just a complexity without much value.

tyleo 4y ago

Incredible, your views are very close to my own. I slightly disagree on encapsulation in that my view is more like, “don’t let it get in the way”. I think this view on encapsulation makes much more sense from the data-oriented side though.

bob1029 4y ago

Data-oriented is the way to go IMO. I am using the latest version of C# and our current domain models use zero inheritance. We also do not allow for any sort of complex type nesting so composition is also constrained. In order to relate complex types together, foreign key properties and dedicated relation types are used. Every domain type we have can be mapped to & from a relational table without any difficulty. This is important because we use SQL for certain parts of the product. Turns out this kind of compatibility has tons of other benefits that you may find value in (we certainly did).

daxfohl 4y ago

How does this apply to problems like filters and emitters for logging as discussed in the article?