Hacker News Reader

Comment by DeathArrow | Hacker News Reader

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

View on HN

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.

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).

Indeed, encapsulation is probably better referred to a minimal coupling. Near zero knowledge interaction. It's a variability principle.

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).

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.

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

> 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.

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.

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.

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.

> 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.

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

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

Sounds like an anemic domain model.

OOP is orthogonal concept to data-driven programming.

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.

Reply on news.ycombinator.com