Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Classes vs. Data Structures

blog.cleancoder.com

Post reply on HN
Print view View original

21–30 of 184 posts

Re: Classes vs. Data Structures

#21

Post by jayd16 »

hudon wrote: post #3

The claim that "an object is a set of functions that operate on implied data elements" has a strange corollary because of how in modern OO languages like Java or C#, there is no syntax or popular naming convention to tell the difference between a data structure and an Object. For example, in Java, a LinkedList object is actually not a linked list, it is a set of functions that operate on an implied linked list. If th…

*DTO is the closest to such a convention as its implied that data representation is the goal.

Re: Classes vs. Data Structures

#22

Post by educhana »

gugagore wrote: post #2

This conversation reminds me of https://en.wikipedia.org/wiki/Expression_problem . I don't understand: "but the existence of the data structure implies that some operations must exist." Grounding it out to a specific data structure, the existence of `List` implies that e.g. `sort` exists? That direction makes less sense than `sort` implies the existence of e.g. `List`(something to be sorted).

SortableList?

Re: Classes vs. Data Structures

#23

Post by _0w8t »

The dependency discussion is wrong. Changing code of a function does not lead to recompilation of callers in most static languages. So if one change circlePerimeter, only that has to be recompiled. But if one changes data structure, then the callers has to recompiled. But this is also true for objects. In C++ changing data typically leads to recompilation of both implicit and explicit data structures. Essentially objects and data structures behaves the same.

Re: Classes vs. Data Structures

#24

Post by mcguire »

"No, ORMs extract the data that our business objects operate upon. That data is contained in a data structure loaded by the ORM."

Technically, ORMs are a set of waldos that you operate inside a glove box in order to manipulate the data in the DB without getting DB cooties on you.

Re: Classes vs. Data Structures

#25

Post by RcouF1uZ4gsC »

>OK, OK. I get it. The functions that operate on the data structure are not specified by the data structure but the existence of the data structure implies that some operations must exist.

This reminds me of Linus's quote:

"

I'd also like to point out that unlike every single horror I've ever witnessed when looking closer at SCM products, git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful ().

() I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

"

https://lwn.net/Articles/193245/

Re: Classes vs. Data Structures

#26

Post by dllthomas »

_0w8t wrote: post #23

The dependency discussion is wrong. Changing code of a function does not lead to recompilation of callers in most static languages. So if one change circlePerimeter, only that has to be recompiled. But if one changes data structure, then the callers has to recompiled. But this is also true for objects. In C++ changing data typically leads to recompilation of both implicit and explicit data structures. Essentially obj…

> Changing code of a function does not lead to recompilation of callers in most static languages.

I don't know how we're quantifying so as to assess "most", but at least in some popular static languages there are circumstances (most notably inline functions) where callers are likely to be recompiled and circumstances (dynamic loading) where they clearly won't be.

> But if one changes data structure, then the callers has to recompiled.

Only if you're changing parts of the data structure that are visible to callers. For instance, if your API operates on opaque handles you can change the underlying data structure however you'd like without recompiling the caller.

Re: Classes vs. Data Structures

#27

Post by pault »

hudon wrote: post #19
danmaz74 wrote: post #9

Earlier quoted context omitted.

In a purely oop language, data structures exist as an implementation detail, but you can never access them directly (as in, bypassing the object interface). That's by design.

I get that in your application, you may want to keep a linked list behind its interface 90% of the time. However, considering your system as a whole, at some point you may want to take that linked list data and write it to a database, in which case the cleanest thing is to bypass the interface and extract the "data structure object" so to speak and deal with it in a database-related object, rather than encumbering yo…

I have these kinds of arguments with my C# co-workers all the time, and they usually have some annoyingly reasonable solution like "create a database serialization class with a linked list consumer". :)

Re: Classes vs. Data Structures

#28

Post by tetrep »

hudon wrote: post #3

The claim that "an object is a set of functions that operate on implied data elements" has a strange corollary because of how in modern OO languages like Java or C#, there is no syntax or popular naming convention to tell the difference between a data structure and an Object. For example, in Java, a LinkedList object is actually not a linked list, it is a set of functions that operate on an implied linked list. If th…

Haskell does address it exactly as you say. Functions and values both being expressions is much less complex. As an example, imagine if you couldn't freely substitute 2+2 and 4. Functional languages say those are the same, imperative languages say one is a value and one is a function call.

It's not particularly intuitive if you're not used to high level math or functional programming, but it really is a lot simpler (not that it doesn't have downsides/leaks in the abstraction, but that's another discussion).

Re: Classes vs. Data Structures

#29

Post by wvenable »

hudon wrote: post #19
danmaz74 wrote: post #9

Earlier quoted context omitted.

In a purely oop language, data structures exist as an implementation detail, but you can never access them directly (as in, bypassing the object interface). That's by design.

I get that in your application, you may want to keep a linked list behind its interface 90% of the time. However, considering your system as a whole, at some point you may want to take that linked list data and write it to a database, in which case the cleanest thing is to bypass the interface and extract the "data structure object" so to speak and deal with it in a database-related object, rather than encumbering yo…

> in which case the cleanest thing is to bypass the interface and extract the "data structure object"

That doesn't seem like the cleanest to me. Instead, you'd use the interface to read/write to the list as you write/read it to storage. At no time do you want to reach into the LinkedList object and access it's internal mechanism.

Post reply on HN