TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Classes Considered Harmful [pdf]

135 点作者 pottereric超过 8 年前

31 条评论

paulrpotts超过 8 年前
Having used C++, Java, C#, Python, Ruby, NewtonScript, Dylan, Scheme, and various other languages &quot;in anger&quot; I can say that in general I agree with the author&#x27;s frustrations. My favorite (as in most flexible, least boilerplate) approaches to object-oriented programming have been:<p>- NewtonScript&#x27;s frames with prototype inheritance. Allows &quot;objects&quot; to consist of very small data structures that point to ROM objects and only use RAM for slots that actually vary, using copy-on-write. The actual implementation had some issues and of course that platform is dead, but the concept was great.<p>- Dylan&#x27;s adaptation of generic functions, with multiple inheritance. There are classes but they don&#x27;t have methods &quot;inside&quot; them. The class hierarchy describes the dispatch for the generic functions. Allows some really nice styles of programming (dispatching on multiple parameters) that are perhaps possible but absolutely hideous in C++.<p>- Qt&#x27;s method. The use of a separate preprocessor step and generated code for dispatch was a hack to get around limitations of C++, but although you don&#x27;t want to look too closely at that generated code if you value your sanity, at a practical level it works pretty well.<p>In summary, I&#x27;d just add that it is a deep and abiding shame of my industry that people wind up in silos learning one model of object-oriented programming and never consider other models that are different and can be cleaner and far simpler to think about.
评论 #13311187 未加载
评论 #13314925 未加载
asavinov超过 8 年前
I like this kind of critical papers but I cannot agree with the author in this case. I have studied this problem quite deeply while working on concept-oriented programming and concept-oriented data model (<a href="http:&#x2F;&#x2F;conceptoriented.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;conceptoriented.org&#x2F;</a>) for many years by also trying to minimize the number of basic constructs. Yet, my conclusion is that classes are actually needed.<p>There are several major reasons for that. One of them is that we actually need two different relations: 1) membership relation, and 2) inheritance (or inclusion in more general case). Unfortunately, we cannot reduce them to one relation. If we do (in prototype-based languages) then normally we will still distinguish the role of this one relation depending on the context.<p>Mathematically, we have the membership relation &#x27;∈&#x27; between an element and a set, and we have the subset relation &#x27;⊆&#x27;. Just as we need both of them, we need both class instances and classes. In other words, if somebody argues that classes are not needed, then it is analogous to the statement that sets are not needed and it is enough to have only membership relation among elements. It is possible to develop such a theory but then we will get an alternative mathematics. Or we will implicitly treat some elements as sets.
评论 #13312029 未加载
评论 #13312041 未加载
评论 #13315278 未加载
评论 #13312733 未加载
评论 #13311962 未加载
Koshkin超过 8 年前
The practical usefulness of classes in C++ comes not from an &quot;object-orientedness&quot; that they supposedly give the language. It comes from the fact that they are merely a <i>mechanism</i> that can be used to create abstract data types, thereby providing a better encapsulation, and do many other things, rather than a <i>policy</i> saying that every object must be an instance of a class. So, one has to be careful when talking about classes, because they may effectively mean different things in different programming languages, even though on the surface they may look similar or appear to serve the same purpose.
评论 #13313491 未加载
评论 #13313447 未加载
ravenstine超过 8 年前
There seems to be a common fixation on objects &quot;modeling the real world&quot; with the counter argument for classes being that they don&#x27;t model the real world. True, there isn&#x27;t a physical chair class in real life(philosophically, there aren&#x27;t even chairs), but there is a common abstract <i>idea</i> of what would describe the function and attributes of a chair. Granted, it differs a little from person to person, but objects themselves are all different in some way. As far as I can tell, in most OO languages, there&#x27;s no reason why classes <i>must</i> use inheritance, though I am certainly willing to be schooled in that regard.
评论 #13310893 未加载
评论 #13310741 未加载
评论 #13311665 未加载
评论 #13312097 未加载
评论 #13312593 未加载
macintux超过 8 年前
Most eye-opening moment in my software engineering class was when the professor asked, of four core OO features (don&#x27;t recall the precise list now), which was superfluous.<p>The answer, of course, was inheritance, and once the question was asked it wasn&#x27;t hard to see how much better life could be without it. I&#x27;ve been on an anti-inheritance kick ever since.<p>Now I see how much better life can be without OO entirely, but that&#x27;s a different discussion.
评论 #13311183 未加载
评论 #13311742 未加载
评论 #13311730 未加载
评论 #13311143 未加载
chowells超过 8 年前
The biggest problem with classes is that they conflate two different concepts in a way that limits reusability.<p>When you have classes, you have subclassing, and subclassing means two different things at the same time. First, subclasses are the subtyping operation. If you want type B to be a subtype of A, B must subclass A. Second, they provide code reuse via inheritance.<p>Each of those things is useful, but there&#x27;s no reason to tie them together. In fact, modern best practices in OO say to favor interfaces and delegation over subclassing, and that&#x27;s precisely because it separates those two concerns.<p>As far as I can tell, this is what the paper was getting at - separating delegation of implementation from subtyping. Since this is already what OO best practices suggest, why is it controversial?
leblancfg超过 8 年前
Although he spends quite some time on exploring the alternatives, the only reason the author specifically states where classes are harmful is <i>because they are premature optimization</i>. That&#x27;s it?<p>I guess &quot;Classes considered a PITA&quot; just didn&#x27;t make a good title.
评论 #13312012 未加载
iokevins超过 8 年前
For what it&#x27;s worth, the footer reads, &quot;Submission to NOOL &#x2F; 2015&#x2F;10&#x2F;12&quot;.<p>NOOL seems to stand for &quot;New Object-Oriented Languages&quot;, a workshop of the ACM SIGPLAN conference on Systems, Programming, Languages and Applications: Software for Humanity (SPLASH).<p><a href="http:&#x2F;&#x2F;2016.splashcon.org&#x2F;home" rel="nofollow">http:&#x2F;&#x2F;2016.splashcon.org&#x2F;home</a><p><a href="http:&#x2F;&#x2F;2016.splashcon.org&#x2F;track&#x2F;nool2016" rel="nofollow">http:&#x2F;&#x2F;2016.splashcon.org&#x2F;track&#x2F;nool2016</a>
评论 #13310411 未加载
noblethrasher超过 8 年前
At least in the cases of C# and Java, classes and interfaces recapitulate a weak form of ML-style functional programming rather an impoverished version of Smalltalk-style object-oriented programming: “Inheritance” from a class corresponds to logical disjunction (and hence is equivalent to a sum type) and “implementation” of an interfaces corresponds to logical conjunction (and hence corresponds to product types). The visitor pattern is a verbose form of pattern matching.<p>You can recover the strong form of ML-style FP (albeit without the nice type inference) if you limit inheritance to abstract classes (thus, all classes are sealed&#x2F;final or abstract), mark all fields as readonly&#x2F;final, and use interfaces for destructuring (which addresses problems 1,2 and 3 under the “Alternatives” section).<p>As an aside, one of the big issues with “classical” OOP is that it enjoins the programmer to create phenomena using logic (i.e. wizardry) rather than of using math to model a system (i.e. science and engineering). Among other problems, this leads to designs that break symmetry (e.g. if modeling a bucket brigade, the perspective of many humans passing by a single bucket should be just as valid and available as the “natural” perspective of many buckets passing by a single human). Of course, appeals to symmetry is question begging, and I don’t have time to litigate that here, but it sure seems like symmetry is key to building scalable systems (where scalability means not just number of users, but also things like number of edits to a codebase).<p>In summary: Classical OOP seems to require that you either have a prior (well-designed and debugged) model against which you can program, or really, really good taste.
brudgers超过 8 年前
Link to <i>The Treaty of Orlando</i>: <a href="http:&#x2F;&#x2F;web.media.mit.edu&#x2F;~lieber&#x2F;Publications&#x2F;Treaty-of-Orlando-Chapter.pdf" rel="nofollow">http:&#x2F;&#x2F;web.media.mit.edu&#x2F;~lieber&#x2F;Publications&#x2F;Treaty-of-Orla...</a>
codr4life超过 8 年前
&quot;I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.&quot;<p>A. Stepanov (<a href="http:&#x2F;&#x2F;www.stlport.org&#x2F;resources&#x2F;StepanovUSA.html" rel="nofollow">http:&#x2F;&#x2F;www.stlport.org&#x2F;resources&#x2F;StepanovUSA.html</a>)
评论 #13314765 未加载
评论 #13315043 未加载
newtscamander超过 8 年前
The premise is the introduction is wrong.<p>&quot;so before we have written a single program in our language, before we know whether shared behaviour will be important in the applications that will be written in it&quot;<p>read the POODR book, or watch this<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;OMPfEXIlTVE?list=PL5s3t9kPeAN6aDxaSywIbeFJOCfm7ixpi" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;OMPfEXIlTVE?list=PL5s3t9kPeAN6aDxaSywIbeFJO...</a><p>it explains how shared behavior works without code duplication and why people tend to mess it up.
pdonis超过 8 年前
Not a single line of code in the entire paper. Without that I have little or no idea what the author is talking about.
bjourne超过 8 年前
I like Factors (<a href="http:&#x2F;&#x2F;factorcode.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;factorcode.org&#x2F;</a>) approach to classes. In that language, a class is a category and not a &quot;mold&quot; from which objects are created. E.g, I can say the following:<p><pre><code> 33 number? t 33 integer? t integer number class&lt;= t number object class&lt;= t </code></pre> The last two lines demonstrates a little of the class algebra possible. It says that if an object is an instance of the integer class, then it also an instance of the number class and of the object class. That is, the set of objects that are integers is a subset of the set of objects that are numbers which is a subset of all objects.<p>I can add new classes which refines categories of existing objects:<p><pre><code> PREDICATE: positive &lt; number 0 &gt; ; PREDICATE: prime-number &lt; integer prime? ; 17 positive? t 17 prime-number? t 13.4 positive? t </code></pre> Note that both real and integer values can be &quot;positive&quot; which means that &quot;positive&quot; isn&#x27;t a strict subset of either class. That kind of refinement isn&#x27;t possible in most oo languages.
scriptkiddy超过 8 年前
I write most of my code in Python. I think that&#x27;s give me a leg to stand on when it comes to discussing OOP.<p>I find that classes, if nothing else, are a fantastic way to namespace data and methods that operate on said data. For instance, if I have a chair object, I could use a class to describe the chair. I could store the materials it&#x27;s made out of, the height of the seat, whether it is an office chair, a barstool, or something else. I could also write methods that can say, price the chair based on data about the chair.<p>In this particular case, I wouldn&#x27;t subclass the chair at all. There&#x27;s no point. Every time I need a chair, I would just create a new instance of Chair. That&#x27;s why chair is an object. It&#x27;s a self contained thing that I can pass around and pull data out of or mutate.<p>I don&#x27;t really use deep inheritance at all in my code. I think the deepest I&#x27;ve ever subclassed something is once. I find inheritance to be useful if I need to be able to create multiple objects that deal with very different things, but perform similar operations on them. A good example of this is Django class based views(it&#x27;s own controversial topic). I created my own resource class to use for handling API specific requests. The methods of pulling filters out of the query string and serializing database objects are exactly the same for every single request, but the objects that these classes operate on are vastly different. Therefore, I need to specify a serialization schema for each database object type, but I don&#x27;t necessarily need to rewrite the function that does the serialization. I use my Resource class in order to more easily re-use these generic methods.<p>Just my two cents.
cousin_it超过 8 年前
I can buy a language without classes if it gives me these things:<p>* Interfaces<p>* Records<p>* Abstract data types<p>* All the above should use foo.bar() syntax<p>Classes provide those things, which is good, but also provide implementation inheritance, which is bad.
评论 #13314608 未加载
usrusr超过 8 年前
Funny how when the author finally arrives at the point where he intends to go from &quot;unnecessary&quot; to &quot;bad&quot;, he has little more to say than &quot;there is no space to repeat it here&quot;.
antiquark超过 8 年前
Hilarious how he blatantly ignores the existence of C++. He talks about Smalltalk, Java, Grace, Emerald, Pharo... but no C++!
评论 #13311788 未加载
MarcusBrutus超过 8 年前
Even in OO languages (such as Java and C#) people are routinely advised to favor composition over inheritance whenever given half a chance. Classes definitely smell (or rather reek) of the infamous 90s that inflicted such atrocities on humanity as the Rational Rose &quot;products&quot; and the UML &quot;methodologies&quot;. It also goes to show why the &quot;typescript&quot; Microsoft strategy is ill thought. Unless of course it&#x27;s simply (as I think it is) the Mother of all Embrace Extend Extinguish strategies in which case it is very cleverly thought. Sadly ECMAScript has also jumped on the OO bandwagon by offering &quot;classes&quot; syntactic sugar but at least it is left to the developer to use it or not, whereas in the Microsoft-land of &quot;typescript&quot; you get classes rammed down your throat.
asavinov超过 8 年前
&gt; &quot;classes do not “model the real world”&quot;<p>Classes are supposed to model sets (of objects), that is, instances represent real objects and classes represent real sets of objects. So the question is whether sets are as real as the members they consist of. For example, if a set of chairs is a reality that we can comprehend and want to represent in the system.<p>Yet, I think the problem is that we are probably not happy how classes model sets in OOP. They actually do not - and it is a major problem. (Classes in OOP are mostly templates for instantiating objects.) Also, we are not happy with how inheritance works and it also limits possible benefits of classes. But it is not a reason to say that classes per se are harmful. I would say that they are not as good as they could be :(
sytelus超过 8 年前
Amount of boilerplate one needs to implement &quot;good&quot; OO design is just horrendous. For example, in C++, previously we had rule of 3. Now its rule of 5! Just having a virtual abstract interface means almost half dozen lines of boilerplate! Even in managed languages such as C# or Java, it would require significant effort to create, say, read-only version of collection given a read-write collection. One of the goal for language design should be to eliminate all these forced boiler plate. It is definitely the time for new paradigm in language design. However I&#x27;m not sure how the &quot;delegates&quot; would solve this which is proposed alternative in this paper.
评论 #13315756 未加载
ap22213超过 8 年前
What is the point of these types of arguments and opinions if they don&#x27;t have any evidence to back them? I don&#x27;t give a shit if it&#x27;s functional or object-oriented or procedural or whatever comes next. I just want a language that is proven, via empirical evidence and reproducibility, to solve my particular use case better than any others.<p>And, given all the use cases I have, I&#x27;d be amazed if one class of language can do it all. I&#x27;m guessing it&#x27;s impossible.<p>It&#x27;s way better for my engineering team to know how to use a bunch of different specialized tools, and how to use them together, than to focus on one type of tool.
neo2006超过 8 年前
IMO language should be designed to be more effective, simpler or powerful, not to avoid programers to miss use them. All the &quot;rules&quot; about not using goto for example are legitimate but people forget that sometimes using goto could be a good practice in some languages. A semantic is just a tool you can miss used it`s programer issue not a language&#x2F;semantic issue. OOP is a way to program among other we can argue that it&#x27;s harder than another or easier but we can&#x27;t say it&#x27;s good or bad, it depend on how you use it and hwo effective you are using it.
评论 #13313481 未加载
wrongdog超过 8 年前
I feel like I just read a lot of opinions by one frustrated dude without a real sense of <i>why</i> classes are bad (or even really why they frustrated him so much). Am I missing something?
评论 #13314561 未加载
keithnz超过 8 年前
so, the argument is it&#x27;s harmful because it&#x27;s a premature optimization? the evidence being simply alternatives to classes? It seems like the paper doesn&#x27;t present a good case for why classes are harmful. Seems the whole premise if flawed based on a glib quote from Knuth<p>Premature optimization ( if that is what classes are ) doesn&#x27;t mean the optimization is harmful. It could actually be really good.<p>The quote means, when you find some evil, and track it back, you&#x27;d find premature optimization. You can also find awesome code, track it back, and also find premature optimization.<p>So, you need to prove classes are evil, and then track it back to premature optimization. This paper fails to do that and therefore fails to make the case for harm
kazinator超过 8 年前
Paper neglects to discuss CLOS approach: generic functions instead of methods, etc.<p>The claim that classes don&#x27;t do object creation because some operator like &quot;new&quot; actually does that is jaw-droppingly stupid.
newtscamander超过 8 年前
The premise is wrong, read the POODR book.
lacampbell超过 8 年前
The paper was a good read. I was kind of dreading it&#x27;d be another tired rehash of attacking straw men from someone who thinks having used Java or C++ makes them expert on OOP.<p>In the early history of smalltalk Alan Kay talks about how he was never entirely satisfied with inheritance, and having inheritance in the language (quoting in full, hard to link to):<p><i>A word about inheritance. Simula-I had neither classes as objects nor inheritance. Simula-67 added the latter as a generalization to the ALGOL-60 &lt;block&gt; structure. This was a great idea. But it did have some drawbacks: minor ones like name clashes in multiple threaded lists (no one uses threaded lists anymore), and major ones like rigidity in the extended type structures, need to qualify types, only a single path of inheritance, and difficulty in adapting to an interactive development system with incremental compiling and other needs for instant changes. Then there were a host of problems that were really outside the scope of Simula&#x27;s goals: having to do with various kinds of modeling and inferencing that were of interest in the world of artificial intelligence. For example, not all useful questions could be answered by following a static chain. Some of them required a kind of &quot;inheritance&quot; or &quot;inferencing&quot; through dynamically bound &quot;parts&quot; (i.e. instance variables). Multiple inheritance also looked important but the corresponding possible clashes between methods of the same name in different superclasses looked difficult to handle, and so forth.<p>On the other hand, since things can be done with a dynamic language that are difficult with a statically compiled one, I just decided to leave inheritance out as a feature in Smalltalk-72, knowing that we could simulate it back using Smalltalk&#x27;s LISPlike flexibility. The biggest contributor to these AI ideas was Larry Tesler who used what is now called &quot;slot inheritance&quot; extensively in his various versions of early desktop publishing systems. Nowadays, this would be called a &quot;delegation-style&quot; inheritance scheme [Liberman 84]. Danny Bobrow and Terry Winograd during this period were designing a &quot;frame-based&quot; AI language called KRL which was &quot;object-oriented&quot; and I believe was influenced by early Smalltalk. It had a kind of multiple inheritance—called perspectives—which permitted an object to play multiple roles in a very clean way. Many of these ideas a few years later went into PIE, an interesting extension of Smalltalk to networks and higher level descriptions by Ira Goldstein and Bobrow [Goldstein &amp; Bobrow 1980].<p>By the time Smalltalk-76 came along, Dan Ingalls had come up with a scheme that was Simula-like in its semantics but could be incrementally changed on the fly to be in accord with our goals of close interaction. I was not completely thrilled with it because it seemed that we needed a better theory about inheritance entirely (and still do). For example, inheritance and instancing (which is a kind of inheritance) muddles both pragmatics (such as factoring code to save space) and semantics (used for way too many tasks such as: specialization, generalization, speciation, etc.) Alan Borning employed a multiple inheritance scheme in Thinglab [Borning 1977] which was implemented in Smalltalk-76. But no comprehensive and clean multiple inheritance scheme appeared that was compelling enough to surmount Dan&#x27;s original Simula-like design.</i>
评论 #13314982 未加载
non_repro_blue超过 8 年前
The meme is becoming lame.<p>Talentless developers who fight and argue are the only real hazard in the world of programming.<p>Mature trends and languages have attracted decades of developers good and bad, and because they&#x27;re widely used, they have the misfortune of also providing a home to the largest corpus of terrible code.<p>Mark my words: in a generation, functional programming will accumulate just as much garbage, inadequately programmed by just as many careless and&#x2F;or passive-aggressive developers desperately clinging to their jobs throughout the next wave of whatever becomes the next Steve Ballmer stack ranking code review process.<p>It doesn&#x27;t matter how many words or ideas you throw at this circumstance. Terrible developers will still manage to commit garbage.<p>Life finds a way.
评论 #13315920 未加载
jackmott超过 8 年前
Computer science gets a lot of papers with arguments for a certain way of doing things.<p>Very few with controlled experiments to find out if a way of doing things is better than another.<p>Every time I mention this, people say that it is hard to do such experiments. Yes, it is hard to actually know things. while it is very easy to make plausible arguments, for almost anything.
评论 #13312463 未加载
评论 #13313391 未加载
BuuQu9hu超过 8 年前
The E programming language, and its newer relatives like Monte, lack classes; instead, objects are defined by object literals and the extends keyword performs object composition by delegation.
评论 #13313732 未加载