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

141–150 of 184 posts

Re: Classes vs. Data Structures

#141

Post by nercht12 »

abecedarius wrote: post #77
chongli wrote: post #55

Earlier quoted context omitted.

A huge difference. Interactively, you can both ask and answer questions and you can steer the dialogue toward the pupil's areas of ignorance. As a form of writing, you're left to guess at what your pupil might be thinking. Apart from Plato, few people have ever managed to succeed at this.

Plato succeeded if you judge by his historical rep, but I can't stand the guy, for reasons not entirely unlike the complaint starting this thread. Though good dialogs do exist (I like Raymond Smullyan's).

Plato didn't imagine his audience to be idiots. He really debated with himself or with questions he'd probably heard other people actually make (since he was with lots of other philosophers). He's harder to appreciate if you don't think like him or his companions and thus don't follow his line of thought.

In a way though, Plato tries to tell a story rather than blabber away facts. It allows for the introduction of stupid or "less-intelligent" questions rather than setting up obvious straw men.

.02

Re: Classes vs. Data Structures

#142

Post by ben509 »

jayd16 wrote: post #33
hudon wrote: post #19

Earlier quoted context omitted.

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…

This is a violation of OOP. Instead, consider methods that produce and consume a serialized representation of the data instead. Things like Java serialization and Python pickle attempt to do what you say and are considered failures (or at least security risks) because they allow a third party to act on object implementation internals. Security aside, a denormalized representation of data could be different than the i…

> ... are considered failures (or at least security risks) because they allow a third party to act on object implementation internals.

Well, not really, in Java you had to opt in, and you could implement the readObject and writeObject methods to override the default behavior; similarly in Python, you can override __reduce__ and friends as needed.

The security problems are more these protocols are essentially executing arbitrary code when reading data. You'd think, "I can specify a root object and then it's going to specify what its attributes can be, and so forth."

But Python is a dynamically typed language so give a class Foo, its attributes can be anything. (Though now with annotations, it is possible to lock down precisely the types you allow; I wrote a module that does this.[1])

Java could have fixed this if they didn't go with type erasure. `List` becomes an `List` at runtime, so there's no way to determine what it ought to contain, short of kludges[2] that other libraries use.

> Security aside, a denormalized representation of data could be different than the implementation specific representation that's encapsulated inside an object.

Yup, as soon as your process has to interact with other processes, even writing to a file and reading it later, it's possible to disagree on how data is represented or what it means. I'll plug another project of mine: I try to make the client smart[3] (enough) to allow versioning[4], as well as avoiding a class hierarchy.

[1]: https://pypi.org/project/json-syntax/

[2]: https://static.javadoc.io/com.google.code.gson/gson/2.8.5/co...

[3]: https://tenet-lang.org/contrast.html

[4]: https://tenet-lang.org/versioning.html

Re: Classes vs. Data Structures

#143

Post by Ace17 »

charlieflowers wrote: post #34
justinpombrio wrote: post #7

The first set of points: > Classes make functions visible while keeping data implied. Data structures make data visible while keeping functions implied. > Classes make it easy to add types but hard to add functions. Data structures make it easy to add functions but hard to add types. is known as the Expression Problem https://en.wikipedia.org/wiki/Expression_problem . The last point: > Data Structures expose callers…

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…

Independent deployability might not be a goal per-se, however it shields teams from other team design choices.

Re: Classes vs. Data Structures

#144

Post by Ace17 »

bendbro wrote: post #40

This doesn't make sense to me: "Right. Now consider the area function. Its going to have a switch statement in it, isn’t it?" Perhaps I am nitpicking, or perhaps I am reading this wrong, but I would not design the square data structure to have a perimeter function. The square data structure should just expose the data that describes a square (length, width). Adding higher abstractions (perimeter, etc) on top of the d…

Nitpicking too: perimeter != area.

Re: Classes vs. Data Structures

#145

Post by Ace17 »

ci5er wrote: post #59
thom wrote: post #39

Earlier quoted context omitted.

The only thing more annoying is when people ape Why's (Poignant) Guide to Ruby and you have to follow the adventures of some tedious otter as it meets the rabbit people who ultimately explain pointers in a way which takes a thousand too many words.

Have you ever come across anything that explains why pointers are hard for some people? I find it difficult to explain pointers to people because I don't understand what they are missing. I could use some help understanding their lack of understanding. When they don't get "indirect reference to the address of a data structure or object in memory", I'm stuck on how to proceed. Pointing people to the very elegant treat…

> I find it difficult to explain pointers to people because I don't understand what they are missing. I could use some help understanding their lack of understanding.

Maybe they don't know what they are missing.

When I was learning C two decades ago, my first thought was that pointers were solving no real problems, and that I will be able to do without them. Then I had to implement the "swap" function.

Re: Classes vs. Data Structures

#146

Post by bendbro »

Ace17 wrote: post #144
bendbro wrote: post #40

This doesn't make sense to me: "Right. Now consider the area function. Its going to have a switch statement in it, isn’t it?" Perhaps I am nitpicking, or perhaps I am reading this wrong, but I would not design the square data structure to have a perimeter function. The square data structure should just expose the data that describes a square (length, width). Adding higher abstractions (perimeter, etc) on top of the d…

Nitpicking too: perimeter != area.

The full quote: "Right. Now consider the area function. Its going to have a switch statement in it, isn’t it? Um. Sure, for the two different cases. One for Square and the other for Circle. And the perimeter function will need a similar switch statement"

I should have stuck with the same metaphor, but regardless of whether it is perimeter or area, the output is a function of the description.

Re: Classes vs. Data Structures

#147

Post by steve-chavez »

> Since the database schema is a compromise of all the various applications, that schema will not conform to the object model of any particular application.

Here it jumps to objects instead of database VIEWs, that can be tailored for each application. There's no need for complex object models when you embrace the db and you don't treat it as a dumb store.

Re: Classes vs. Data Structures

#148

Post by jmkni »

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; }
  }
You can check to see if something is a Data Structure like so:

  typeof(Foo).IsValueType (true)
  typeof(Bar).IsValueType (false)

Re: Classes vs. Data Structures

#149

Post by jayd16 »

Silhouette wrote: post #116
jayd16 wrote: post #109

Earlier quoted context omitted.

>An alternative is to specify the representation explicitly and provide a set of functions designed to work with it, but also to allow direct access by other functions when that is useful. I don't see that as an alternative. I consider this natural OOP. You don't lose anything by strictly enforcing the encapsulation because you can always explicitly provide low level methods into the data structures. Conversely, you…

You don't lose anything by strictly enforcing the encapsulation because you can always explicitly provide low level methods into the data structures. But then you're not really gaining anything either, unless perhaps you have some mechanism to enforce that the low-level access should only be used in specific circumstances when it is deliberately intended. It's like writing classes that have a few data members, but th…

I think to some degree its a matter of opinion but I couldn't disagree more.

The argument for abstraction at the procedure level seems obvious if you've ever used an interface or private members.

I think you have some picture in your head where everything has to be abstracted in a needlessly obtuse way to be an object. If you have some DTO, the fields are the contract so its fine if they're public. (In Java in particular its easier to refactor if you use the getter/setter pattern but that's not an OOP issue.)

I mean, I really don't understand what you're advocating here. Everything should be public?

Re: Classes vs. Data Structures

#150

Post by Silhouette »

closeparen wrote: post #131
Silhouette wrote: post #116

Earlier quoted context omitted.

You don't lose anything by strictly enforcing the encapsulation because you can always explicitly provide low level methods into the data structures. But then you're not really gaining anything either, unless perhaps you have some mechanism to enforce that the low-level access should only be used in specific circumstances when it is deliberately intended. It's like writing classes that have a few data members, but th…

You can change the internal representation while doing transformations in the getter to preserve compatibility. With collections, you can export contents through an Iterable, or to Array, or any number of other strategies, without coupling the consumer to your internal representation.

Of course, but what I am questioning here is how often we really do change internal representations of simple data structures. The theoretical benefit of hiding every representation behind an interface is clear, but any abstraction also has a potential cost if it creates a barrier to doing something useful and/or becomes leaky.

You can still provide standardised interfaces for things like iteration along with a data structure even if you choose to expose the specific representation, so I am not sure how strong an argument your second point makes. Depending on the situation, you may find your consumer is implicitly coupled to the true representation anyway, perhaps because it inadvertently relies on values being iterated in sorted order or insertion order or because it assumes certain performance characteristics even if these things are not strictly part of the documented interface. More than once in programming history, even standard libraries of popular programming languages have been updated to guarantee some behaviour that had been reliable in practice but was never actually part of the original specification.

Post reply on HN