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

161–170 of 184 posts

Re: Classes vs. Data Structures

#161

Post by pjmlp »

kstenerud wrote: post #129
charlieflowers wrote: post #34

Earlier quoted context omitted.

Regarding the claim ... > Data Structures expose callers to recompilation and redeployment. Classes isolate callers from recompilation and redeployment. ... most projects (maybe all?) I've worked on in 20+ years deployed a full set of new bits upon release, rather than trying to differentiate at the level of which source code files were and were not touched. So this strikes me as a carryover from many years ago when…

C++ is still painfully slow to compile, and seems to get slower every year.

While it still is definitely worse than other compiled languages, using pre-compiled headers, with incremental compilation, incremental linking does help a lot.

And making use of binary libraries as well.

Eventually with C++20 modules the situation will improve, and maybe by 2025, those that still care might finally enjoy Delphi compile times with C++.

Re: Classes vs. Data Structures

#162

Post by jcelerier »

kstenerud wrote: post #129
charlieflowers wrote: post #34

Earlier quoted context omitted.

Regarding the claim ... > Data Structures expose callers to recompilation and redeployment. Classes isolate callers from recompilation and redeployment. ... most projects (maybe all?) I've worked on in 20+ years deployed a full set of new bits upon release, rather than trying to differentiate at the level of which source code files were and were not touched. So this strikes me as a carryover from many years ago when…

C++ is still painfully slow to compile, and seems to get slower every year.

> C++ is still painfully slow to compile, and seems to get slower every year.

oh come on. I can get a full build of qt5's main libraries (core, gui, widgets, network, xml, etc) in 15 minutes on my laptop. It took an hour a few years ago. Compilers are getting faster all the time.

Re: Classes vs. Data Structures

#163

Post by roelschroeven »

narag wrote: post #63
Jach wrote: post #43

Earlier quoted context omitted.

Part of this reminds me of discussing the differences between "data structure" and "algorithm". Sometimes it's hard to separate them, especially since many algorithms don't need anything more elaborate than "get" and "put" into some opaque data store. Add requirements on the data store that make it less opaque (can't "put" for instance, making it immutable) and your algorithms change. Change your algorithms and you m…

Careful. The author is not using "data structure" with the standard Computer Science meaning, but as C language struct. Standard data structures were actually the equivalent to current classes and were associated with a set of functions. If you bother to take a look to C APIs, you'll find the familiar "handle" parameter, equivalent to the "this" or "self" of OO languages. Setting aside all the philosophical mumbo jum…

> The author is not using "data structure" with the standard Computer Science meaning, but as C language struct.

The text would have been a lot clearer if that would have been more explicit from the beginning!

Re: Classes vs. Data Structures

#164

Post by eska »

danmaz74 wrote: post #151
DeathArrow wrote: post #136

People are starting to use data oriented design instead of OOP. Data oriented design doesn't hide state, is generally faster and easier to comprehend as it doesn't abstract too much. https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=yy8jQgmhbAU https://www.youtube.com/watch?v=rX0ItVEVjHc

Data oriented design makes sense in video games where perfomance Is very important, but in most business applications having good abstractions which are flexible and easily maintainable is much more important than optimising for cache usage.

I keep hearing this from OOP proponents, but I just don't find it to be true in my experience. Programs written with DOD in mind have very clear data flow and only pass on and use data that is relevant. Programs written with OOP in mind primarily care about some notion of beautiful code and abstractions, which I find to be highly subjective. As a result they generally have very muddy data flow where e.g. unrelated data is passed around that isn't even required to implement a feature. This creates all kinds of poor modularization, dependency hell, huge monoliths, difficult testing (mocking, fakes, etc...), among many other problems. Whenever I have had to rewrite large parts of a program, I have always found it to be easier to do this in a DOD program rather than an OOP program. The biggest reason why DOD is used in video game programming to begin with is flexibility in mixing and matching functionality of game objects (entity-component-systems etc).

Re: Classes vs. Data Structures

#166

Post by _pmf_ »

jmkni wrote: post #148
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…

> ...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. In C#, you create a class when it's an object, and a struct when it's a data structure, or am I missing something? ie: // Data Structure public struct Foo { public string Bar { get; set; } } // Object public class Bar { public string Foo { get; set;…

> In C#, you create a class when it's an object, and a struct when it's a data structure, or am I missing something?

Yes and no. Due to the technical limitation that (unlike in C++[0]) structs in C# cannot derive from other structs, DTOs in C# are often implemented (or rather: generated) as classes to allow derivation from a base class that has certain behavioral hooks (say, for misc. custom serializers).

[0] See https://www.fluentcpp.com/2017/06/13/the-real-difference-bet... (the real technical difference between struct and class in C++ is just that the default visibility modifier for a struct is public and the default visibility modifier for a class is private; both can use inheritance and have virtual methods)

Re: Classes vs. Data Structures

#167

Post by Aromasin »

I enjoy the authors "question/answer" style of writing. I often find myself asking questions just like this when reading an article, and find that when the author isn't "question focused" they never get answered. It seems that when the entire writing style pivots on the idea, the author forces themselves to consider more Q's to pad out the content and, incidentally or otherwise, provide more A's.

Re: Classes vs. Data Structures

#168

Post by jmkni »

_pmf_ wrote: post #166
jmkni wrote: post #148

Earlier quoted context omitted.

> ...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. In C#, you create a class when it's an object, and a struct when it's a data structure, or am I missing something? ie: // Data Structure public struct Foo { public string Bar { get; set; } } // Object public class Bar { public string Foo { get; set;…

> In C#, you create a class when it's an object, and a struct when it's a data structure, or am I missing something? Yes and no. Due to the technical limitation that (unlike in C++[0]) structs in C# cannot derive from other structs, DTOs in C# are often implemented (or rather: generated) as classes to allow derivation from a base class that has certain behavioral hooks (say, for misc. custom serializers). [0] See htt…

Cool thanks

Re: Classes vs. Data Structures

#169

Post by b0rsuk »

mannykannot wrote: post #76

Why does every software example always involve shapes? Because they allow us to avoid discussing the complications that arise when entities have lifetimes, over which, at different stages, different operations are meaningful.

Because it's one of the very few cases where class inheritance is an elegant solution.

Re: Classes vs. Data Structures

#170

Post by roelschroeven »

kasey_junk wrote: post #82
ci5er wrote: post #67

Earlier quoted context omitted.

Hmmm. Interesting. I'm going to have to roll that around in my brain for a day-or-so to see if I can make that compute for me. (Which means I may be back here in a day to check back in!) Maybe it's because I started in assembly language, but to me, data exists at an address in memory. Or starting at an address in memory. That data might be on integer, a float, a character, the beginning of a string, the head of an ob…

Note that your model is also an abstraction. Modern architectures move data around between a variety of memory locations (and store it in multiple locations) which are all addressed via the pointer ‘transparently’. It’s not really a memory address anymore and hasn’t been for some time. That’s not to say your model is bad, it’s the same one I have in my head. But it’s no more ‘real’ than coordinates or library cards o…

Isn't it still the model that is exposed to the programmer, even though internally all kinds of things are going on to make it all go faster? For example, nowadays many/most processors have separate caches for instructions and data, meaning that they strictly speaking don't conform to the Von Neumann architecture. But the programmer doesn't see the different caches, ideally doesn't even see the cache at all.

It's like the execution model, where processors do a lot of out-of-order execution, but do a lot of work so they can present a model to the programmer as if everything happens in-order.

Post reply on HN