Classes vs. Data Structures

311 点作者 Anchor将近 6 年前

28 条评论

DeathArrow将近 6 年前

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.<a href="https://www.youtube.com/watch?v=QM1iUe6IofM" rel="nofollow">https://www.youtube.com/watch?v=QM1iUe6IofM</a> <a href="https://www.youtube.com/watch?v=yy8jQgmhbAU" rel="nofollow">https://www.youtube.com/watch?v=yy8jQgmhbAU</a> <a href="https://www.youtube.com/watch?v=rX0ItVEVjHc" rel="nofollow">https://www.youtube.com/watch?v=rX0ItVEVjHc</a>

评论 #20210523 未加载

Jach将近 6 年前

I guess this applies for Java and C++ style "classes". This does not precisely apply to the first ANSI-standardized OOP system, Common Lisp's. Standard classes do not own methods, instead methods are specializations of a generic function that stands alone and dispatches on the class types (or EQL values) of all its arguments.I'd really like it if Uncle Bob eventually has his fill of Clojure and moves on to explore what Common Lisp built decades earlier, then blogs about that too.

评论 #20209717 未加载

评论 #20209701 未加载

评论 #20209159 未加载

评论 #20208825 未加载

评论 #20210048 未加载

hudon将近 6 年前

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 the system needed direct access to the data for whatever reason, we'd need to explicitly have a LinkedList data structure object that only contained the data (the values and their pointers), as well as a second class, the LinkedListOperator, that contains all the functions (add, first, etc.). Likewise, in the author's examples, there'd be a Square class and a SquareOperator class.I was going to say that Haskell addresses this by putting values in data types and behaviors in "type classes", but then I remembered that functions can be values... which is now making me think that the reality is probably more abstract or complex than the author here is letting on.

评论 #20207167 未加载

评论 #20206732 未加载

评论 #20206840 未加载

评论 #20210477 未加载

评论 #20206976 未加载

justinpombrio将近 6 年前

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 <a href="https://en.wikipedia.org/wiki/Expression_problem" rel="nofollow">https://en.wikipedia.org/wiki/Expression_problem</a>.The last point:> Data Structures expose callers to recompilation and redeployment. Classes isolate callers from recompilation and redeployment.is only somewhat true. I suspect it would be more accurate to say that it's a matter of indirection: static dispatch isolates callers from recompilation; static dispatch exposes callers to recompilation; calling a function pointer isolates callers from recompilation; calling a function directly exposes callers to recompilation. (All of this in statically typed languages.) Though this isn't my area of expertise. Perhaps someone else knows more? [Edit: sounds like these "expose" cases often don't cause recompilation either.]

评论 #20207431 未加载

RcouF1uZ4gsC将近 6 年前

>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."<a href="https://lwn.net/Articles/193245/" rel="nofollow">https://lwn.net/Articles/193245/</a>

评论 #20222587 未加载

评论 #20207308 未加载

gugagore将近 6 年前

This conversation reminds me of <a href="https://en.wikipedia.org/wiki/Expression_problem" rel="nofollow">https://en.wikipedia.org/wiki/Expression_problem</a> .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).

评论 #20206553 未加载

评论 #20207871 未加载

评论 #20206995 未加载

725686将近 6 年前

Maybe a little tangential but it immediately came to my mind Alan Perli's quote: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." I think I first heard this from Rich Hickey and made so much sense.

h8liu将近 6 年前

What the author calls "objects" (or "classes") is really often just "interfaces".> An Object is a set of functions that operate upon implied data elementsIf this is replaced with:> An Interface is a set of functions, often operate upon implied some implied data elements (but not necessary).Everything in the article will probably be less confusing.

F_J_H将近 6 年前

And while the discussion takes place and the debate rages between classes vs. data structures, there's some poor analyst or data scientist who just needs access to the damned data to load it into a pandas data frame to do things that those designing the objects and data structures never dreamed of in the first place...

atoav将近 6 年前

Interesting read. What immediately sprung to my mind was Rust's Trait system which sort of manages to give you the best of both worlds. With Traits you can implement common behaviour/functions for multiple datastructures.When I started using Rust I wasn’t used at all to seperate data and behaviour that strictly, but it makes sense. OOP paradigms were still hardwired in my head so the hardest part was actually wanting to do it in that decoupled way. Something about a car object that has wheel objects and a car.drive() function gives you a good feeling as a programmer, but sometimes it is more effective to stay with the data structure and describe the car as a struct of vectors which implement a Driveable trait..

skybrian将近 6 年前

Thinking about client-server architecture (for example, a database) can clarify things.Encapsulation means you never have the canonical data. The server is the system of record. You can get data back in response to queries, perhaps even a full data dump, but it's a snapshot. You can also send commands to mutate data on the server. Typical applications aren't allowed to do a complete replacement (restoring from backup).On the other hand, data is better thought of as what's going over the network. Messages consist of data. Encapsulation is almost meaningless; if you want to keep something private from the receiver, don't include it in the message in the first place (or use encryption, maybe). Anyone reading the data has to be able to understand the format, or at least, ignore what they don't understand.In the degenerate case where the caller and implementation live within the same process, the same types often get used both for message transfer (in function arguments and return values) and storage. There is widespread "cheating" for performance reasons, and it can get confusing. For a transient process, it might not make sense to think in these terms at all. (Traditional Smalltalk used persistent images and client-server style encapsulation makes somewhat more sense there.)You can also "cheat" by using the same schema for data transfer and storage, or having a trivial mapping between them. This can introduce unnecessary coupling, but there are systems where it works. (Consider that you can make a full clone of a git repo and it doesn't encapsulate any data.)

hotBacteria将近 6 年前

I like the shapes problem because I actually encountered it and it made me think.I'm not sure about the switch approach described in the post:<pre><code> function area(shape) switch shape.type case "square": return shape.side ** 2 case "circle": return 2 * PI * shape.radius case "triangle": return ... case "segment": return 0 case "polygon": return ... ... case "oval": return ... </code></pre> You can have a lot of cases, some of them requiring non trivial code... Eventually you write a function for each case and it's more work than adding a method for each shape because you still need to write the switch...Classes seem work better than structures here.But then you want to handle intersectionsThe switch approach doesn't seem realistic:<pre><code> function intersection(shapeA, shapeB) if(shapeA.type == "circle" AND shapeB.type == "circle")... if(shapeA.type == "circle" AND shapeB.type == "square")... if(shapeA.type == "square" AND shapeB.type == "circle")... ...//uh oh you have nShapes**2 cases to handle </code></pre> But java classes or not better: where do you define Circle-Square intersection? In Circle? In Square?Even with multiple dispatch the solution is not ideal. You now have some things related to Circle (area, perimeter...) in the Circle.blub file, and intersection(Circle, Circle) wich only works with Circles is now in intersections.blub...I don't see a good solution and sometimes I feel like the problem is more with our tools (code in text files) rather than programming paradigms

评论 #20211906 未加载

评论 #20215473 未加载

_0w8t将近 6 年前

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.

评论 #20207076 未加载

mannykannot将近 6 年前

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.

评论 #20211246 未加载

solinent将近 6 年前

A class is fundamentally about implementing object semantics. This simply means everything (eg. all objects) are an instance of some class. It has methods which can be used to operate or communicate with other objects or itself.Data-structures are put most simply as ways of organizing data. The organization of the data implies a specific layout--a way of representing your data as a table of integers, ie. in RAM.After reading the article, I don't see a meaningful distinction between objects and data structures. A data structure can be represented as an object, especially in OOP languages where it must be.A general class doesn't necessarily lay out its data in any particular way--which allows abstraction over the data representation of the class.However, some classes are made which are designed in a manner which guarantees a certain data layout. std::vector with its contiguous memory requirement comes to mind.To add to this, the c++ conception of a "concept" or haskell's concept of a "typeclass", or even a generic class, is really what this article is talking about. Or even Java or Go's interfaces. There is absolutely no way to guarantee a specific data structure through an interface, typeclass, or concept, since they fundementally do not mention their data representation at all.

Aromasin将近 6 年前

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.

评论 #20221688 未加载

bendbro将近 6 年前

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 data structure only serves to create the trumped up problem later described in the dialog. The perimeter method should be defined in the Square class, where perhaps a "StraightLinesOnlyPolygonMixin" could define the perimeter method.In general, I cannot see why a Data Structure would define computational methods. You are tightly coupling logic to the underlying data source, which is wrong when that logic obviously could apply to any underlying data source (I don't care if my square is backed by RDB, S3, a hardcoded instance, etc) The perimeter method, and probably the Square class, should be the same.

评论 #20207777 未加载

评论 #20210169 未加载

steve-chavez将近 6 年前

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

mcguire将近 6 年前

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

tydok将近 6 年前

Classes vs Data Structures, or maybe Objects vs Data Structures, or maybe Classes vs Objects, or maybe Data vs Data Structures, or maybe Data vs State, or maybe Classes vs Types, or maybe OOP vs FP, or maybe I don't know what I'm talking about...

micimize将近 6 年前

Seems to me that with the definitions given, structures and objects aren't opposites, they're corollaries.A database table is both a data structure and a collection of functions for accessing/manipulating it (SQL). An ORM maps between the "Object Oriented" objects and the "Relational" objects that are tables.Interesting the author thinks about the the api exposed by a table as the "data structure" itself rather than an object. Pragmatically, we tend to refer to the "objects" at the lower level of abstraction as data structures. Is [...] a function that defines an array, or the array itself?

nfrankel将近 6 年前

Am I the only one who has trouble with the dialog form?

评论 #20210938 未加载

sdegutis将近 6 年前

This is really hard to follow and I'm not sure I'm understanding it the way he intended.Correct me if I'm wrong, but he seems to be saying that, to avoid breaking consumers of your library often by changing the implementation, hide the implementation details behind classes, right?This seems to be a common reaction to someone who experiments with the "freedom of functional programming" where that freedom means operating on and returning raw data structures that OOP usually hides behind private variables.That's still bad practice, even in code that heavily uses FP, and good code usually mixes FP and OOP properly, so that you're given functions when you're meant to have functions, and data when you're meant to have data. This is how I've been writing JavaScript for a few years now, and it's not how I've seen Java or Clojure usually written.

评论 #20206856 未加载

flakiness将近 6 年前

Was surprised how Uncle Bob getting better at trolling these days. He's been provoking, but somewhere in recent years he turned himself to a troll. (Or he's just talking to his audiences, who aren't HN readers.)

mistrial9将近 6 年前

very interesting and worthwhile! Data has gravity; and data dependancies are more costly than code dependancies, are two lines that are current.Objects may possibly have broader uses that what is described here ("business data applications") but within the definition given, the description of Object and operations on object make a lot of sense. This post is worth re-reading a few times.

stupidcar将近 6 年前

Whenever I hear "Socratic dialog", I reach for my revolver. Is there any other form of teaching so irritating and patronising? You might have a brilliant store of insight to impart, but if you insist on trying to do so via a twee, affected and unbelievable conversation with a Mary Sue wise professor, I'm going to write you off as insufferable before the fawning moron you have as proxy for your audience utters their first "Oh, wow! So you mean that straw-man you just put in my mouth isn't true?"

评论 #20207884 未加载

评论 #20207669 未加载

评论 #20207863 未加载

评论 #20207502 未加载

评论 #20208726 未加载

评论 #20208356 未加载

评论 #20207746 未加载

评论 #20209094 未加载

评论 #20209019 未加载

评论 #20208361 未加载

评论 #20208130 未加载

评论 #20208593 未加载

评论 #20208062 未加载

评论 #20208116 未加载

评论 #20208183 未加载

bcp2384将近 6 年前

Not every language is class-based...

gowld将近 6 年前

When Uncle Bob discovers subclasses, friends, decorators, and mixins, his mind will be blown.