6 ms·

I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming. Or they're using hyperbole that

• chx 8y ago
  > You want to know why OOP is useful and common? Because it's easy. With as much proof as you have given, let me offer you a counterargument: it is common because academia loves OOP. It's easy to teach, it's easy to test. It is most decidedly not easy and very often not useful. My favorite example of how everything falls apart in due time is the color of a car. That's it, right? A car has a color. A Porsche Panamera might be a "carbon grey metallic" and it's stunning, but that's just one color still. Aye, up until the Mini Cooper tells you they need two colors. This world doesn't fit the OOP straightjacket. Your programming course does but the real world doesn't and when it doesn't then pain follows.
  • devocracy 8y ago
    Refactor, with the right IDE this should take minutes. OOP witbout something like intellij or VS.NET is not fun.
    • kangoo1707 8y ago
      What does OOP has anything to do with your IDE. I think you are referring to typings
      • deleted 8y ago
        [deleted]
      • VLM 8y ago
        OOP is often excruciatingly verbose and boilerplate which an IDE can help with. You can do LISP in vi or emacs just fine, but for java some kind of IDE to handle the sheer data processing load of source editing is necessary.
  • wedowhatwedo 8y ago
    Why is color of a car an issue with OOP? Without knowing your the use cases, neither of us will model it correctly for the job at hand. A car obviously has multiple colors. It has at least two: exterior and interior. Quite often there are two-tone colors. But as a manufacturer, I'm going to guess that each interior and exterior color scheme has an ID. If you are a car manufacturer, the interior and exterior color scheme ID would be all you need.
    • TheOtherHobbes 8y ago
      car -> list of parts -> part.color Although in fact you should probably allow for composite parts with multiple sub-colors, where each part supports its own enumerated list of possible colors. In spite of appearances, it's not a completely trivial problem. Maybe OP meant that to someone doing naive modelling, defining a car class and then giving it a single color property is going to cause problems. Which of course it is. And maybe also that OOP encourages this kind of superficial thinking. Initial ignorance - and initial assumptions - about the problem domain get baked into the architecture. It becomes increasingly hard to change them as time passes and code grows around them. Essentially, OOP mixes up data schema and software architecture in a brittle way. Of course you can build abstract classes for variable schemas, but then you're really doing meta-OOP, and there are probably better options. OOP isn't the only paradigm that does this, but the brittleness seems to be characteristic. If you keep your schemas separate and explicit it's not usually all that difficult to extend/change them. If they're buried in class definitions and you don't have a dependency map to see which part of the schema is used in which part of the code, non-trivial refactoring can become a complete nightmare.
  • antialias 8y ago
    You seem to be translating a modeling failure into an indictment of the whole object modeling paradigm. Your car model doesn’t account for multi-color liveries? Revise and refactor the model. Adapting to change isn’t the same as falling apart.
  • mabbo 8y ago
    Okay, so how would you model that in a different paradigm? And why could OOP not model that the same way? Your example also doesn't specify a business context. What kind of software am I building such that I need to model a car and it's color? That simple question will entirely change how the OOP model is designed. OOP is easy to teach because it's easy to use, to understand. But again, if you use simple poorly thought out OOP, it may work- just badly. And of course there's the problem of "those who can't do, teach" and often those teaching programming are poor programmers.
  • scarface74 8y ago
    In the real world? If I’m programming in a monolith, I change the Color property to a List and I get a big red dot with the number of errors the change caused in the bottom of my IDE and it tells me all of the places I need to change the code. If my car class is part of a Nuget package. I change the version number to represent a breaking a change following the standard semver semantics. When the consumer upgrades to the latest package, they either get warnings about Color being obsolete and use Colors instead or I just completely remove the Color property and they get a red dot and change their code or decide they don’t have time and keep the old package around for awhile. If I’m writing an API, and since I did properly separate my domain model from my view model, I both map the first item in the Colors list to the Color property in my view model and I create another Colors property. These are solved problems.
  • fmap 8y ago
    > it is common because academia loves OOP. Absolutely not! I doubt that anybody was ever taught OOP in an academic PL course, unless it was really an "introduction to programming" course, or their professor was working on this topic at the moment. The meaning of a program in an object oriented language with imperative features and inheritance is not pretty. There are aspects of object oriented programming that are useful for structuring programs (hidden state) and others which are a recipe for disaster (recursive types). This complexity is always swept under the carpet when teaching OOP. Classes/inheritance/objects are always taught via imperfect analogies, which should tell you everything you need to know about how "easy" OOP really is. No, the reason it is taught so widely is purely practical. It's a popular paradigm and a lot of practical programming projects might need an OOP background. --- Edit: Just to be clear, I'm not trying to say that OOP is bad per se. The information hiding and namespacing aspects of objects are really useful, both in theory and in practice. It's just that I think that implementation inheritance is an imperfect way of facilitating code reuse and not something you should teach to new students...
    • scarface74 8y ago
      The information hiding and namespacing aspects of objects are really useful, both in theory and in practice. It's just that I think that implementation inheritance is an imperfect way of facilitating code reuse and not something you should teach to new students... And most professionals agree with you. “Prefer aggregation over inheritance.” Which by the way Resharper makes really easy. You add a private variable to your class of the type you want to aggregate and it creates wrapper methods in your aggregating class that just calls your other class.
    • brians 8y ago
      It’s in SICP, leading up to the adventure game project. That dominated intro-PL conversations for a long time. Also, it’s OO with delegation-based inheritance, prototypes—and some discussion of why.
  • jasode 8y ago
    >it is common because academia loves OOP. Maybe we're exposed to different evidence but it seems like academia heavily favors non-OOP such as functional programming. Programmers also make repeated citations to SICP class they enjoyed in college but were forced to deal with OOP when they got a real job. It's the commercial industry that pushed OOP. Universities seem very anti-OOP while commercial businesses like Adobe/Microsoft/Google use OOP languages like C++. Other companies that write back office "enterprisey" software also favor OOP languages like Java/C# over non-OOP such as Haskell. I also remember the 1990s when professional programming magazines had monthly articles evangelizing the new thing called "object oriented programming" and you had full-page ads for Turbo C++ and Microsoft C++ that touted its new OOP features. >My favorite example of how everything falls apart in due time is the color of a car. That's it, right? A car has a color. A Porsche Panamera might be a "carbon grey metallic" and it's stunning, but that's just one color still. Aye, up until the Mini Cooper tells you they need two colors. This world doesn't fit the OOP straightjacket. I don't understand why your example as you've constructed it proves what you want it to prove. If we use your "car color" as a text template to test the validity of other computer science ideas: Database table paradigm: create table car ( vehicle_id varchar(20), color_code varchar(1) ); ... but a car like Mini Cooper can have more than one color. The world doesn't fit the relational table straitjacket. Algebraic data types such as product type: struct { char vehicle_id[20]; char color_code[1]; }; ... but a car like Mini Cooper can have more than one color. The world doesn't fit the algebraic data types straitjacket. The world also doesn't fit structs. It doesn't fit the char data type, or array of chars, and so on. It seems like your example applies to any and all computer science concepts that attempt to model real-world data so maybe I'm missing something?
  • segmondy 8y ago
    It's not OOP that's the problem, but your mental model. There's no OOP language that says a car has to have one color. You can define an object to have more than one color, or maybe instead of having a color have a color pattern. How creative is your imagination? If you use a tuple of (r, g, b) to represent color in a functional language, you will still have the same problem when you realize you can have multiple colors or design patterns. if your mental model has a mismatch with the real world, you will have problem at some point.
    • mercer 8y ago
      Sometimes it's not primarily that it's impossible to model this stuff in OOP, but rather that the change in requirements over time can be more difficult to implement in an OOP codebase. At least that's been my experience.
• fermienrico 8y ago
  New to OOP programming. Could you explain what sort of arguments are presented against using OOP? I am genuinely curious.
  • hliyan 8y ago
    I've been programming for 15 years (so I was around for the rise of OOP). There's nothing fundamentally wrong with OOP. I still write a lot of classes. But what I haven't written in a almost a decade: code with inheritance, encapsulation or polymorphism. Nothing has exploded. Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions). This is OK User user = new User("John"); But this: StringTokenizer st = new StringTokenizer(str, ","); while (st.hasMoreElements()) { System.out.println(st.nextElement()); } Might not be as clean as: stdout(tokenize(str, ",")); // functions are hypothetical
    • scarface74 8y ago
      I was about to reply in C# that would usually be done with LINQ, but then I realized I kind of just proved your point since LINQ is functional programming not OOP....
    • _old_dude_ 8y ago
      Thank you for posting this snippet of code, to me, it acts like the episode of the madeleine in the Swann's way. as you said, nowadays people are using String.split ``` List.of(str.split(",")) `` which is less poetic.
    • theprotocol 8y ago
      Excellent examples. Minimalist OOP can be beautiful, but over-abstraction e.g. `FactoryObserverFactory` is absolutely disastrous.
    • naasking 8y ago
      > Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions). Except these aren't objects, they're just records. I don't think it's a good idea to pollute the word "object" or OOP. You use objects specifically when you need procedural abstraction, otherwise you use other types of values, like products/records, sums/variants, etc. At high system levels, where you have client/server or other types of protocols, objects fit. At lower levels other paradigms tend to be better.
• jstimpfle 8y ago
  Yes, OOP is easy. At least the layers of sedimentary cruft were comparatively easy to write. The parts that actually do something, not easier in the slightest. It's still procedural code that must move data. (Usually that code is much less straightforward in OOP because it has to deal with so much boilerplate that is in the way of accessing the actual data).
  • zbentley 8y ago
    > The parts that actually do something This comes up a lot, and I think there's a broken assumption here. The core business logic of a product "actually does something", to be sure. But that doesn't mean that all the other code is somehow less important or pointless. Code that allows multiple people to work on the same abstractions in slightly different ways "actually does something" too--it facilitates cooperation and interoperation. Test code "actually does something" too--it helps prevent issues and ensure quality. All of those things can be done wrong (core algorithms can have bugs, abstractions/interfaces can confuse people, tests can lie/test the wrong things), but they're all equally necessary in many cases. I think the misconception about non-core-procedure code being "cruft" automatically comes about because very early on in small projects, you don't need much more than the core. But when projects grow (to more people or just more code), other goals, like standardization/maintainability/extensibility/testability, become just as important as the goals of the core: if your added engineering staff can't add value to the company, or if your software is fatally buggy, it doesn't matter how good the shape of the original core-ideas code is, you'll lose money.
    • atoav 8y ago
      I had similar thoughts. Before I started learning how to program Rust. All your arguments ( standardisation, maintainability, extenseability, readability) are true, but they are not necessarily always brought to you by (ab-)using OOP. I experienced that OOP can be at times something that can make people see everything as a nail, because all they have got is a hammer. In the end a lot of the real work a piece of code is the transformation of data. OOP often distracts inexperienced programmers from this, which leads to unnecessary complexity in bussiness logic and interfacing alike. Thinking in the line of data transformation is useful because you will focus on two things: how to do this transformation fast/simple/extensible and what the most useful abstraction over said transformation is. You can (and given some complexity, must) achieve all of the mentioned attributes without using classes at all. And sometimes taking classes away can make things so much better.
• gameswithgo 8y ago
  No true Scotsman. >Because it's easy There are lots of cases when forcing yourself to stick to OOP styles or programming is much less easy. You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples. I don't mind having classes that can inherit available in a language, but languages like Java and C# that force you to use only those things leads to a lot of unecessary boilerplate. You can work around this with static classes full of static functions that you can treat as 'modules' full of free functions. Which, is what I do a lot :D But I wish I didn't have to bother with that workaround.
  • mpweiher 8y ago
    > You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples. People have done this methodically, and the results may surprise you: http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm That's the one from 1996, there was a newer one that pretty much confirmed the results.
  • scarface74 8y ago
    I agree. Even in Domain Driven Design, sometimes you just have transaction scripts. Call a spade a spade and write your code accordingly.
  • zippy5 8y ago
    I would suggest that boilerplate is small price to pay for having a compiler enforce design discipline and conventions. Remember that code should be written for both the run time environment and next coder who will have to understand it. Constraints enforced in java often make it easier for the next dev. I suspect part of this is that in unconstrained languages, there are so many ways of doing the same thing that pattern recognition become more difficult for all but the most experienced programmers.
    • naasking 8y ago
      > pattern recognition become more difficult for all but the most experienced programmers. In fact the opposite is the case. The boilerplate obscures underlying patterns because it forces you to read twice as much to infer the same amount of information. Roughly the same design patterns are used in more expressive languages, just without all the boilerplate. This makes the pattern being employed completely obvious since it's only a few lines of code.
• letstrynvm 8y ago
  It's maybe confusing because you are presupposing OOP as the default. Humans tend to observe some situation and sythesize stories to explain it, even when it comes to observing their own actions. I don't mean to unfairly paraphrase but to transpose what you wrote so it shows these stories you are telling yourself - usually people criticising OOP are "bad programmers" - OOP is easy, alternatives are hard - Even if OOP model is a bad fit, it's still a model and the extra devs needed to solve its bad fit can easily be chained to the oars - If OOP makes trouble, it was because it was "done badly" - Most easy things work well enough even if "done badly" (that is just not true) - If OOP can be cobbled together to work at all, it is justified since that justifies anything If you consider a simpler proposition like, "this can be done in a few hundred or thousand lines of C99 instead of latest C++ and boost", I think there is just no valid reason to bring OOP into it.
  • scarface74 8y ago
    Even when I was writing C, I had different modules in different files, only exposed certain functions via the header files and had structs with function pointers that did different things based on how the struct was initialized. This was before I knew anything about OOP. How is this any different than object oriented programming?
    • undreren 8y ago
      It isn't. Not in a significant way at least. I think the main benefit of OOP isn't really abstraction, like modules, because even function signatures coupled to a struct definition can be a great abstraction. Abstraction is about generalizing something in order to hide its inner workings. Modules can do that just fine. What OOP "got right" was to make it easy to use indirection to pass function pointers. That way, you can easily create pluggable systems at runtime, so that strategies can be dynamically chosen. Passing function pointers in c can be pretty tedious, if you need to send implicit state with it. I've started to get really annoyed with indirection though. It's getting abused so thoroughly in order to make bad designs testable through dependency injection. I find that it is much easier to use dependency rejection instead.
• PopeDotNinja 8y ago
  > You want to know why OOP is useful and common? Because it's easy. Try rewriting that without adjectives. Engineers are very convincible, but they need evidence. Personally, I don't find OOP to be particularly useful or easy. Check this out... "I became a much better programmer when I started writing functional code. Now I tend to write OOP code in a functional way, but learning how to do that was and not easy, and I am not sure most would find it useful." By saying that, I'm basically taking a position that's the opposite of yours, and while it's true to me, it provides no evidence for you to help you evaluate my side of the conversation.
  • e40 8y ago
    My problem with OOP is debugging it when things go wrong.
    • candiodari 8y ago
      But this is often the result of the good property of OOP software. OOP software is easy to write, and allows for easily abstracting over problems. The net result is OOP programs tend to be more complex. Not "more complex than equivalent software". More complex. But also more capable, more abstract, easier to extend, at least along foreseen lines, easier to change (although that's mostly a tooling thing I think). But yes, bigger, more intricate software is more difficult to debug. Also abstractions don't help, because often the problem is that there are edge cases where the abstraction doesn't work. Also debugging with abstractions require you to know and understand what the abstraction does.
• naasking 8y ago
  > I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming Every paradigm can implement any type of program needed, in principle. The point of criticising a paradigm is to argue to what extent that paradigm encourages that bad programming you mention. If OOP naturally frames problems in a way that leads most people to bad solutions for common problems, that's a legitimate criticism.
• deleted 8y ago
  [deleted]
• dragonwriter 8y ago
  > OOP will be here forever Being the overwhelmingly dominant paradigm of the nineties and early oughts, largely because it was better for large scale programming than simple procedural and got bolted on in a very backwards compatible way to the overwhelmingly dominant procedural language of the immediately preceding period doesn't mean it is going to be around, in a significant way, forever. > You want to know why OOP is useful and common? Path dependence, its superiority for large products over what was dominant just before, the dominance of C before OOP became common, and the near simultaneous introduction of C++ and Objective-C which framed the debate about how to move beyond C (which C++ won, which is why not only is OOP dominant, but static class-based OOP on the C++ model, both strucurally and syntactically, is dominant within OOP.)
• atoav 8y ago
  Sometimes there is just no right way when it comes to using OOP. Sure OOP is often a hammer that will make everything look like nails, but for some problems it really just isn’t the right approach at all. For a very good example when this is indeed the case, watch (or read!) this amazing talk by kyren on Game ECS: https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html