A Healthy Hatred of OOP, or the principles of my message-driven framework

87 点作者 rlt3大约 9 年前

19 条评论

jasode大约 9 年前

Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples...>Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information. The getX() and setX() is an anti-pattern of good OOP.>Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. No, good OOP has class/object with both private state and associated functions combined to provide a public interface for clients to use.(Although Java & C# (unlike C++) may have muddled this aspect because their language specification does not allow "free" functions to live in a plain namespace. Therefore, programmers are forced to use the "class{}" keyword with static functions as a workaround. Maybe that's where your "holding pen" characterization came from?)>A traditional OOP approach uses shadowy architecture to remove the responsibility of an object,No, good OOP tries to push responsibility into classes/objects so they can act as independent agents with minimal coupling to the outer context they sit in.I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is. Unfortunately, it's like trying to argue against Javascript because of overuse of "eval()" or arguing the flaws of Haskell because variable names are often 1 character long.There are definitely problems with OOP but they are not the bullet points you mentioned.

评论 #11480417 未加载

评论 #11480606 未加载

评论 #11481699 未加载

评论 #11480360 未加载

评论 #11481174 未加载

评论 #11480868 未加载

评论 #11481044 未加载

评论 #11480491 未加载

评论 #11483379 未加载

评论 #11483037 未加载

评论 #11483437 未加载

评论 #11481618 未加载

评论 #11481700 未加载

barrkel大约 9 年前

The OOP referred to in this article is certainly a straw man, but the alternative suggested has problems too.Teams that work well act almost like they're mind-reading one another. High quality orchestration of disparate parts is in tension with encapsulation.Actor-based programming is highly concurrent but in my experience it's harder to reason about as it scales up. Emergent behaviour of interactions between hidden states is sometimes the goal, and sometimes an unwanted side-effect. Network protocols are tricky to get right for a reason; splitting everything out into a shared-nothing message-passing architecture isn't a panacea.I lean more towards explicit but immutable data structures, and referentially transparent functions over those data structures. In this world, parallelism can increase performance without observable concurrency. Concurrency is the root of non-determinism; non-determinism should be avoided unless it's inherent to the problem at hand.OOP is a middle ground in this world, but it's ill-defined. Depending on style, it can be stateful and imperative, functional or message-oriented. OOP is not an absolute bad; with effort, it can be massaged, or herded, into working patterns. But it's certainly not a universal optimum.

carsongross大约 9 年前

A traditional OOP approach would have much of the functionality taken out of the player objects, using them simply to hold state. I don't agree with that characterization. The author certainly has a point that, in some languages in particular, like java, there tend to be massive over-decomposition of problems into reams of factories, controllers, controller factories and controller factory manager factories, but that isn't OOP, that's due to cultural and syntactic issues with those languages. (I know, I know, No True Scotsman.)In the Rails world, which is a non-trivial component of the broader OOP software world, there is a saying: "Fat Model, Skinny Controller" which is much more in the spirit of what the author is advocating, despite remaining OOP.Again, this isn't to deny the authors general point, but I don't believe it is bound to OOP, so much as it is to a certain style of OOP coding that arose from early (java in particular) over-engineering and excessive decomposition.

ninjakeyboard大约 9 年前

I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind-- Alan Kay, OOPSLA '97

rdtsc大约 9 年前

Joe Armstrong's thoughts on how Erlang is more OO than OO languages:<a href="http://erlang.org/pipermail/erlang-questions/2009-November/047748.html" rel="nofollow">http://erlang.org/pipermail/erlang-questions/2009-November/0...</a>Joe likes to be funny, so don't get upset and confrontational about it.The central idea is this I think:---I now believe the following to be central to the notion of OO.<pre><code> - Isolated concurrent things - Communication through message passing - Polymorphism </code></pre> All the other stuff (inheritance, private/public methods, ....) has nothing to do with OO.---

评论 #11481064 未加载

评论 #11480888 未加载

markbnj大约 9 年前

>> When I started learning C++ I was shocked. Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. Instead of communicating between themselves, objects were operated on by some bigger parent object. I found it absurd and fought it for a long time.This has nothing whatsoever to do with C++. It's like blaming a microwave oven because your kid put a ball of tin foil in it.C++ is a great language when you are developing big compiled programs and need strong metaphors for decoupling and modularity. Most developers today work on distributed systems where the individual cooperating pieces that they write are much smaller. Your 1000 line HTTP handler in python won't benefit much from strong static type checking, but the linux kernel does, and so do a lot of the infrastructure components we all take for granted every day.

评论 #11481995 未加载

paulddraper大约 9 年前

One of the more ironic titles I've seen.Alan Kay (progenitor of Smalltalk and OOP) has said on various occasions that it should have been called message-oriented programming, rather than object-oriented."I'm sorry that I long ago coined the term 'objects' for this topic because it gets many people to focus on the lesser idea. The big idea is 'messaging'"<a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html" rel="nofollow">http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...</a>

nbevans大约 9 年前

The same thing happened with REST, TDD and Microservices, etc. The term gets hijacked by people that are less than skilled at executing it. And unfortunately there are more unskilled than skilled people in software; so usually the hijacked term wins the contest. It then takes decades of the "original guy" sending out a BBS message / IRC message / vBulletin post / Blog post / Tweet / HN comment / etc to try to correct people's understanding by saying "actually, that's not canon!".

copx大约 9 年前

Comment on the code:As a Lua aficionado I hate to see stuff like this:<pre><code> Ball = {} Ball.__index = Ball function Ball.new (x, y) local table = {} setmetatable(table, Ball) table.x = x table.y = y return table end </code></pre> Explicit setmetatable() call and manual __index setting? You can automate this and hide all the metatable magic = less code to write, less potential for bugs.E.g. in my own Lua object system the above would be:<pre><code> Ball = Class() function Ball:Properties(x, y) return { x = x, y = y } end</code></pre>

KirinDave大约 9 年前

I think that we suffer from a paucity of precise language around OOP. Everything is OOP, everything is what Kay created, etc.But that's clearly not the case, and so people have these radically divergent systems of programming within the framework of "object orientation".My read of this article and it is very message-passing OO to me. Its broadcast mechanism is interesting, for sure. But it reads a lot like Erlang's supervision tree without all that troublesome thinking about a network.But it's approach is still very "OO".

daxfohl大约 9 年前

The downside of message passing is debugging. No call stack so you can't trace things back to their source.

评论 #11480478 未加载

评论 #11481340 未加载

评论 #11480877 未加载

评论 #11480894 未加载

评论 #11480689 未加载

amelius大约 9 年前

The only good thing that OOP brings to the table is, in my opinion, access control.

评论 #11480620 未加载

sbov大约 9 年前

Isn't this basically event driven programming?

koder2016大约 9 年前

> Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information.In pure Actor Model adding two numbers would probably involve 2+ actors, yet Erlang is not doing this for some reason... I guess on a lower level hardcoding messages makes complete practical sense.

lucb1e大约 9 年前

Some meta feedback on the article: this font is too big to comfortably read on mobile, fitting about five to seven words on a line (the typically recommended line length is about 14 words).

qaq大约 9 年前

How does this make fp? If we fill fp with plugs for 1 man projects with 1 watcher we'd have 1000s of entries a day.

andrewmcwatters大约 9 年前

The less actual code I see in articles like this, and the more abstraction I read about, the less I take the concept seriously.In fact, all of this seems like bullshit to me. The actual code inside of the repo is, well, object-oriented. How I interpret this is that the author seems to have no idea what they're even talking about, and that they write more about code than they write code itself.Show me what you mean, don't just talk about it.

评论 #11480465 未加载

CyberDildonics大约 9 年前

TLDR: Terrible programming practices end up putting blame on labels and languages.

andrewvijay大约 9 年前

The more I read about functional programming the more I question why are things this hard in traditional oops. If so many people have been doing oops for so many years then it must have something that is easy to pick up or something that is easier to work with. But after doing some functional programming the number of lines are painfully less and the code is easier to understand. I was thinking may be I was giving too much credit to FP but I was not it's simply just the way things are. But why has FN been used only as an academic tool and not as a goto programming paradigm? Can someone shed some light on this?

评论 #11483900 未加载

评论 #11482536 未加载