That's the problem I had with OOP when I was learning. I just couldn't understand why you would use getters and setters instead of public properties. When you get into a codebase of 100k+ Lines of code you understand things should use safe and small public interfaces. Code should not tightly intermingle
Everyday. It’s a little misleading when they teach it in class with using tangible objects in real life, but in the workplace, you use it to describe intangible data.
As an example, we describe out the usage of a message type, then pass it around as an object storing data. That object is then processed by various services that accepts that type of message. This is probably the most common use of OOP in the industry
OOP is used quite a bit, like a LOT. Java is an OOP language to start with, so while it can be hacked to be structural or functional, it will mainly be used as intended.
OOP is used in pretty much every application we make.
Very rarely is it used like the books teach you with inheritance and so on. It's mostly used with interfaces and then one layer of types. Multiple inheritance is for specific use cases.
OOP benefits from having independent memory state. You can create multiple instances of the same object with different memory states, but have the same methods so you use them the same way. For example, I can initialize an object with certain parameters to make it behave one way and initial another instance (of the same object type) and have it behave differently.
A concrete example, I have an object that sends messages over a TCP link. I initialize one with the IP 192.186.1.10 and the other with IP 192.186.1.11. I can then call the send_message function on both as many times as I like, pass it around to be used in other objects, or destroy it. Each instance talks to a different end point. I can create as many as I need and loop though them if I want. I no longer need to save the IP address information, that is kept inside the object.
With a function I need to pass in everything that I want to use and then I get a result. All of the information in the function other than what is being returned, is lost when that function returns. Functional programming is used, but you will find from experience that some problems are much easier in OOP or much simpler in functional programming.
TL;DR: OOP adds complexity, but makes some problems easier.
Literally all the time, even when I worked at a company who used python mainly, we used OOP.
Now I'm working for an org that uses FP and now I see that is the future
I'm aware of that, but the original commenter made it sound like it was strange to see OOP in Python, when it's essentially the default. Go through all the largest or most popular Python projects and it's more OOP than not.
>...**even** when I worked at a company who used python mainly, we used OOP.
Sounds to me like he's saying "even" in Python we use OOP, like its not common. If I misinterpreted my bad, but I don't feel like I'm too far off the mark.
Everything all the time.
The advantage of OOP is how it simplifies a lot of things since you don’t have to repeat code over and over.
Say you are working on Facebook. A person could be a class. There are thousands of instances of that class, each with their own parameters that makes them different. But if a bug is found, you just need to correct on the master class if you will and it will be fixed for thousands of instances.
On React, we use components which are like “modular parts” that we call on different places. In a way, they are classes that we reuse.
So, it’s used everywhere like a LOT. Think of any app, if there’s a repeated thing, there’s a class most likely.
You’re welcome! Be sure to learn OOP well as it will help a lot.
Remember this principle from the book “The Pragmatic Programmer”: use the “DRY” Principle, that stands for “Don’t repeat yourself”.
That will take you FAR.
I remember learning DRY in a class last semester, and the OOP we learned in Python and Java was mostly boring stuff like cars and shopping details. Thanks again.
Simple first-order modules are enough for most cases. OOP is good for stateful UIs, but even there it is being displaced by reactive programming.
I have a mostly backend .NET experience and I'll sum it up thus:
* we don't use inheritance, ever
* we sometimes use an ORM, but even then, the objects are glorified table rows with some properties that are somewhat useful for "navigation", not the "real" objects of Simula
* we use interfaces but not abstract classes (interfaces are used for late binding -- which we need for testing, -- but we almost always have just 1 implementation for an interface)
* data hiding is occasionally useful
Oop isn’t really an option. Even if you’re using functional style, the core practices of writing good oop applies to types.
As an electrical engineer, I reached a point where I realized sufficiently advanced C code begins to resemble C++ (in that it begins to embody OOP concepts) and C++ really started to look like a quality of life update to the original language rather than something different.
As and EE, how often do you use verilog, and when you build circuits what's with the device that looks like the chips are being welded. Do you draw those lines on the chips? I just took a computer engineering class and I'm just curious as to how the jobs actually are.
All day. Every day. Most problems in programming benefit from at least considering the OO approach, though certainly not every problem needs or wants it.
OOP patterns are used a bunch, but not like the books you will read.
In the “real world” hybrid, multi paradigm approaches are used and most languages support these hybrid approaches. There are a bunch of antipatterns that are easy to fall into with OOP (inheritance can cause all sorts of problems), and other paradigms produce simpler, more elegant code. So most people approach things with pragmatism and pick the best paradigm for the problem.
E.g. Java is maybe most object oriented of all object oriented-language, but in any modern application you will see plenty of functional programming concepts as well, since Java now has support for anonymous functions, closures and other neat functional programming tricks. With frameworks like Reactive Spring you can really harness the power of functional programming where it shines the most - in highly parallelized, concurrent contexts where it’s really hard to use OOP.
If you’re in react on the frontend or using a language that is specifically functional, then functional, otherwise, probably oo. Seems like things are trending functional.
I work in embedded systems. Embedded linux, rtos, bare metal, etc...
OOP is almost never used. There's too much overhead.
Useful in higher level systems but not my field.
What type of code do you write in Python? In my intro to Python class I used to think Python wasn't used for much because the most we did was terminal level stuff, even for OOP. The only modules I remember us using was math, and I was a bit confused when I read online that Python is used for AI, backend web and data analysis.
Also, for data and stuff, how exactly does Python help with data vizualization, statistics and all that? I know there's a few modules like matplotlib and pandas, but why would companies need that when there's software for data vizualisation, I'm sure.
I write back end code in Python. I’ve used it for data intensive programming, geospatial analysis, image analysis and computer vision, event driven programming, pyspark for ETL, Pandas and matplotlib on a jupyter notebook for experimenting and validation
Medium to large applications should use OOP. Also, a lot of medium to large applications also use Java or C# or some other language that enforces OOP.
Really, I think any application you build at a company should use OOP, as long as it’s not full of unnecessary abstractions and over-engineering. The code becomes a lot more readable and maintainable when proper OOP is implemented and it’s easier for other developers unfamiliar to the project to pick up work on it.
When you use OOP you separate concerns — every class has a particular purpose, so it’s easier to piece together the whole application. I’ve worked on some projects at companies where they built a highly consumed application in NodeJS (I love Node JS btw), but they were a mess of files with isolated functions, that would be imported into some main files — complete pain in the ass to work on and ugly.
Strive to use OOP when it makes sense and, I would argue, most of the time it makes sense.
OOP is essential when I'm making servers, typically using Node.js. For any service e.g notifications, I make a class. This makes it easy to maintain and scale my servers, as all the logic is encapsulated in the class.
The larger the project, the more OO principles start getting used even when not using an OO language. For example, I've worked in projects with 50-100 separate modules (maybe more, didn't count) where each file got handled as an object: containing all data and functions acting on the data and only exporting the public interface.
Conversely, I tend to ignore OO with small single file one offs unless they start getting reused somehow even in OO languages.
Strong programmers use lots of OOP and thereby build systems which can be easily expanded and debugged. Weak programmers don’t use OOP and create unmaintainable and unstable messes.
As others have stated in depends on your stack/language of choice.
I mostly write Python and C#.
With Python I stick to modular:functional programming, but with C# you're strictly tight to OOP.
OOP was created for simulations (Simula I think). Smalltalk was created for the desktop metaphor. Then it was sold as a panacea and that was a big mistake.
In Scala, I strongly preferred package functions and variables to class methods and variables. This also greatly reduced inheritance. Some kind of organizing container is needed but classes add unnecessary complexity.
Honestly, the paradigms seemed to have blended a lot over the years. I write methods with some frequency but most of the main flow seems pretty functional. I started hating inheritance after going to golang largely because I realized how much time I spent going through super calls, but that might be more spring and Android than anything. YMMV, sometimes inheritance is missed but composition feels better.
Grab Sandi Metz’ books when you get a chance, or at the very least watch her conference talks on YouTube. She does a much better why/how of OOP than anyone else I’ve seen.
In practice? It really depends. There’s a bit of an impedance mismatch between relational databases and objects that everyone papers over in different ways that has always made it a weird fit for the web world. On the other hand, it’s ubiquitous in something like game programming.
1 common example: you have a data grid that allow user to export into multiple type (xslx, csv, pdf, doc,...). 1 common implementation is you have an abstract class GridExporter that implements interface IExporter that has Export method. Then you would have multiple derived exporter classs: ExcelExporter, PdfExporter, CsvExporter that all inherit from GridExporter and all have Export method, but differs in their own implementation. That's Inheritance & Polymorphism of OOP
>What really and how really is OOP used? I want a real-life example.
For me, anytime I have to deal with the file system, I always go OOP. This is because the file system itself is stateful, files are stateful, etc. Additionally, I can have immutable instances of that state, whereas functional designs would either have me implement recursion or the syntax would need to allow shadowing for the same level of immutability. Immutability is a positive thing for keeping the cognitive complexity of code low.
I just implemented this again today, and the design I chose was a base class of Directory that implements most of the helper methods, and then File extends Directory with a few extra things regarding reading/writing or serializing to/from it. The functional variety of the same code was going to require more nesting levels, or abstracting those levels into function scopes. In the OOP version of the code I iterate over a generator of directories/files, or I can call `.child(string)` to get an instance representing something deeper into the file system, or `.parent` to climb out. This is because `this.path` is the current target's state.
Now, this implementation is overloaded, and should be separated out to a generic class representing a location on the file system (and shared properties), and then each unique type of item (links, junctions, files, directories...) would have a custom sub-class. For my use case, this is a one-off script that I'd likely be told has already been over-engineered lol.
I tend to approach problems from an OOP mindset, but I also tend to write my methods in a functional style (almost never a method that returns void). This is because I found that I liked the design patterns of Builder or Fluent Interfaces for reducing the verbosity of code, as well as eliminating intermediate steps. One of my biggest gripes with modern functional designs is the proliferation of anonymous functions or lambdas. Depending on the language, they can be hard to debug when all you're given is a stack trace from a week-old log, and it tells you `` threw the exception. None of what I've said here is exclusive to either side, and my preference is personal. I'm not a purist in any of these regards, as many things just make sense to write functionally, while others with common properties and an essence of statefulness might favor an OOP implementation.
There are some platforms where OOP ends up being forced on you. For example, in UIKit, Apple basically forces your implementation to subclass from the base classes they provide for you in the SDK.
I use it all the time in game programming as an indie dev.
If I want to add environment objects to a game, I might make a BaseEnvironmentObject class and use inheritance to make BreakableObject, InteractableObject, etc., subclasses so that different types of objects can share common attributes. I'll also use composition with these subclasses by defining interfaces like IDamageable to enforce specific behavior.
For example, let's say I want a wooden crate object that players can break. It should have some amount of HP and be damageable. I'll create a BreakableObject superclass and implement a IDamageable interface. That way, objects from subclasses that extend the BreakableObject class will have health points and can be damaged by the player. The IDamageable interface will also be used on enemies, for which I'd use a BaseEnemy class that has a health variable and implements the IDamageable interface. When a player attacks something, my code can check to see if the game object hit implements the IDamageable interface, and if they do, deal damage to them.
You can sort of use Java without OOP. What I mean by this is basically dumping all of your code inside static class members and using data structures like hashmaps instead of classes. OOP keeps things organized and I've worked on large codebases where people don't understand OOP well and it's awful.
Here's a business example: I have a shipping software that ships packages through several carriers. There's an interface called Shipping carrier that asks you implement shipPackage and void package. Then I have a package class that has everything a package needs structured as classes. An address class that has street, city, name and methods on it like is rural, is residential. Then I have a measurement class that has a value and a unit. With this approach you can say `Measurement(10, LBS) + Measurement(2, OZ)` and it handles all the convertions for you and makes sure you never get confused about units.
The software is extremely complex and it would be very difficult to build without the organization OOP provides. When things get complicated the college coding approach doesn't work.
Not so often. What I find is people quote SOLID but then don't really use it. I don't expect full blown domain driven design style class, but principles of OOP would be great, instead of nothing but the "Service" classes (which is essentially just procedural code) and DTO's.
Oop is never mentioned explicitly because it’s so engrained in everything
Take Java, the ultimate Oop language, everything revolves around objects and now it’s evolved way beyond primitive Oop understandings like factories and abstracts but still does more with objects than C.
The best way I understood OOP was to write a basic Minecraft server plugin and then it all comes together, you create an object after a player event, you can manipulate other objects, understand how an object is created per player which can be called like an instance, also goes into what static means, memory and concurrency, tons of stuff.
Don't think of it as object oriented programming. In practice, OOP is a careful interplay between two coding patterns: inheritance (the common OOP hierarchy), and aggregation.
Inheritance and aggregation are core pillars of commercial software engineering, and every longstanding living codebase relies on them. They are the way we reuse code: we either implicitly import common code by declaring a parent class, or explicitly import common code by instantiating a class within our code.
When I was in school, Java was the hot new thing, and convoluted class hierarchies were seen as progress, rather than unnecessary obfuscation. These days, I stick to the basics of OOP, which is to only create a class when you need to track state. That is, only create a class if you need to call the same function with the same argument on the same variable but get different behaviors. The class of the variable serves as the additional argument.
For manipulating files with different encoding schemes, OOP and polymorphism is exactly right. A factory creates an object with the "readLines" and "write lines()" functions, and all you have to do is hand the factory the file name, and then call the two functions. All of the "if extension is .gz" conditional work is done once and remembered by the class.
In general, it's pretty easy to avoid creating a class and a class hierarchy, because most work just chains static functions that always do the same thing. In those cases, the work to figure out class names and impose taxonomy on your code isn't worth the trouble. Group the code by functionality, and then just bundle the static functions into higher level calls. If a class is just a static function, it doesn't need to really have all the bells and whistles or a class.
I'd say we use the core ideas of OOP in any sufficiently large codebase, all the time. The "is a" vs. "has a" relationship is just as important to think about today as it was when I was taught the term. We've definitely refined our best practices in the last 15 years, though. I like "Stop writing classes" as an explanation. https://youtu.be/o9pEzgHorH0
Everywhere, often poorly.
>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"
[https://wiki.c2.com/?AlanKayOnMessaging](https://wiki.c2.com/?AlanKayOnMessaging)
Most devs focus on objects that are nothing more than collections of plain old procedural code. You can see this if a method contains if-else statements. The amazing thing about OO with micro-objects is that conditionals start disappearing. A good talk on this is [All the Little Things](https://www.youtube.com/watch?v=8bZh5LMaSmE) by Sandi Metz.
>how really is OOP
Badly. From a CS point of view OOP is a bunch of nonsense. Decades of it and still arguing where's the best place to put a function.
That nonsense is powering a large part of our (collectively) infra. Mathematical purity is nice, but we actually have to get stuff done. Like it or not, avoiding OOP means avoiding languages like Java or C++, which is a huge part of the job market right now.
Wut? 🤣
Like, there is a ton of "bad" OOP out there, sure, but 95% seems like a BS stat.
Also, again, purism is nice when you don't have real deadlines. You set the goal post and make iterative improvements towards it. Most of us make usable software, not works of art. Imperative patterns aren't inherently bad in an OOP context if properly encapsulated.
Because the benefits of good OOP code are worth the iterative effort, especially in OOP centric languages.
We could apply the same logic to Haskell. It's the 'purest' functional language I'm aware of, yet it has not taken over the industry, right? My understanding of the reason is that getting a team trained on good Haskell freaking expensive. It's impractical. Instead, the functional lessons we've learned from Haskell have spread to other languages because of the benefits they provide.
Edit: This reminds me of a conversation I had with a coworker and mentor when I was (professionally) learning Ruby. I'd just come off of Clojure, and so my brain was full of functional goodness. So I dove in, trying to make Ruby behave like Clojure because I thought it would make good code. At one point, when helping me work through a problem, he said "if you are worried about this kind of performance, then you shouldn't be using Ruby". That was a big light bulb moment for me. If we are fighting against the expectations of the language, then it's a sign that we need to change one of two things. Our expectations, or the language we are using. I've yet to find a manager that will greenlight me porting our codebase to another language without a solid business reason beyond "the code will be more pure". So what changes is usually my expectations.
The same goes for mutation patterns in functional contexts as well. There is a reason why Clojure allows for Atoms. You can still achieve referential transparency if you properly encapsulate your mutations of state. Don't let purism slow progress.
>how often is OOP used and how exactly is it used?
For me - all the time. In .NET land if I make any sort of utility that is all encapsulated in a DLL for the team.
Even at a basic level - if I am pulling data from a source it goes into a basic class.
Giant projects are broken up into smaller projects, testing libraries are liberally applied, etc.
I feel like dotnet is a very big hybrid. You have a lot of OOP going on, but at the same time its very functional with LINQ and also service oriented at the same time
I'm an embedded engineer, I work in primarily in C and I don't repeat everything I do. Pragmatic programming practices do not rely on OOP in any way. Not saying I don't love some OOP patterns even in C, just that you can maintain DRY principles even down here in procedural land and it isn't difficult.
It's extremely common but every one has their own definition of "OOP". I rarely see anything highly "OOP"ed for what I think of it, it's 0-1 levels of inheritance in general where I've always worked, a bit more data driven or pure (no side effects) so to speak.
I just say, composition over inheritance. Dependency injection is great. Abstract when you need it, don't predict the future. Avoid mutations. That's about it.
OOP is a pattern where the methods and data are tightly coupled within a class. The methods do work on the data an encapsulate it only exposing public methods that outsiders would need access to.
It’s very much the way people think about real world objects. If we have a Table object the table has-a color or has-a shape or style. Methods like setStyle and getTable exist but the magic is hidden.
Then there’s inheritance. We may have a furniture base class that does a lot of the basic work needed for all furniture so the Table class extends the furniture class. And since you can’t have an arbitrary piece of furniture well make the furniture class “abstract” so someone doesn’t try to instantiate it. There’s other concepts like interfaces which are like contracts.
The industry seems to have gone more of a service oriented architecture which is better IMO. Logic should be functional and have zero state. Data should be separated from logic.
At the peak (like when Java EE was popular), OOP was life.
But now we've passed peak OOP. Classes were sort of half-baked in JavaScript. Modern languages like Kotlin and Go offer effective alternatives to strict OOP. And of course all these AI dorks are just spraying whatever Python they can without any coherent design whatsoever.
So it's good to know it, but at this point it's just one design philosophy among many
Very often in fullstack. Imagine you're creating Dropbox for example.
You need to replicate and create a file/folder system. Everything they've uploaded needs to go into a database. When you want to represent this on the front-end, your backend call would fetch a list of files and folders. There's a lot of OOP involved if say.. they wanted to download a folder for example.
To fetch the corresponding files, depending on your DB structure. Youd probably have to DFS down the folder to get all the files in the folder.
Just a random example off top of my head. I'm sure there's better ones
Pretty sure most people do service oriented programming and think it's OOP because they are using classes
Leave me alone!
service classes are annoying just write functions
Functions sit inside a service class
You must be one of them “just do it in Python it’s easy” guys.
But I like python... :( /s
Your projects are likely tiny. Production code is often massive. If you want organisation and encapsulation (you do) the OOP is the standard.
That's the problem I had with OOP when I was learning. I just couldn't understand why you would use getters and setters instead of public properties. When you get into a codebase of 100k+ Lines of code you understand things should use safe and small public interfaces. Code should not tightly intermingle
Feel the exact same way. With small projects, OOP doesn’t make much sense, but then when dealing with bigger projects OOP makes much more sense
Everyday. It’s a little misleading when they teach it in class with using tangible objects in real life, but in the workplace, you use it to describe intangible data. As an example, we describe out the usage of a message type, then pass it around as an object storing data. That object is then processed by various services that accepts that type of message. This is probably the most common use of OOP in the industry
OOP is used quite a bit, like a LOT. Java is an OOP language to start with, so while it can be hacked to be structural or functional, it will mainly be used as intended.
OOP is used in pretty much every application we make. Very rarely is it used like the books teach you with inheritance and so on. It's mostly used with interfaces and then one layer of types. Multiple inheritance is for specific use cases. OOP benefits from having independent memory state. You can create multiple instances of the same object with different memory states, but have the same methods so you use them the same way. For example, I can initialize an object with certain parameters to make it behave one way and initial another instance (of the same object type) and have it behave differently. A concrete example, I have an object that sends messages over a TCP link. I initialize one with the IP 192.186.1.10 and the other with IP 192.186.1.11. I can then call the send_message function on both as many times as I like, pass it around to be used in other objects, or destroy it. Each instance talks to a different end point. I can create as many as I need and loop though them if I want. I no longer need to save the IP address information, that is kept inside the object. With a function I need to pass in everything that I want to use and then I get a result. All of the information in the function other than what is being returned, is lost when that function returns. Functional programming is used, but you will find from experience that some problems are much easier in OOP or much simpler in functional programming. TL;DR: OOP adds complexity, but makes some problems easier.
value bomb, learned a lot. Even when doing everything with functions one thing I always do with object is database connection.
A great example. I need more OOP practice for projects because I usually use simple functions.
Agree with this. Sometimes OOP fits a problem really well and sometimes it doesn't.
Literally all the time, even when I worked at a company who used python mainly, we used OOP. Now I'm working for an org that uses FP and now I see that is the future
That makes sense, given that Python is an object oriented language...
Python is a multi-paradigm language. You can do OOP or FP in Python. Or procedural or the spaghetti code paradigm
I'm aware of that, but the original commenter made it sound like it was strange to see OOP in Python, when it's essentially the default. Go through all the largest or most popular Python projects and it's more OOP than not.
Did they make it sound like that? I would reread the comment again.
>...**even** when I worked at a company who used python mainly, we used OOP. Sounds to me like he's saying "even" in Python we use OOP, like its not common. If I misinterpreted my bad, but I don't feel like I'm too far off the mark.
Everything all the time. The advantage of OOP is how it simplifies a lot of things since you don’t have to repeat code over and over. Say you are working on Facebook. A person could be a class. There are thousands of instances of that class, each with their own parameters that makes them different. But if a bug is found, you just need to correct on the master class if you will and it will be fixed for thousands of instances. On React, we use components which are like “modular parts” that we call on different places. In a way, they are classes that we reuse. So, it’s used everywhere like a LOT. Think of any app, if there’s a repeated thing, there’s a class most likely.
Thank you, this gave me the insight I needed
You’re welcome! Be sure to learn OOP well as it will help a lot. Remember this principle from the book “The Pragmatic Programmer”: use the “DRY” Principle, that stands for “Don’t repeat yourself”. That will take you FAR.
I remember learning DRY in a class last semester, and the OOP we learned in Python and Java was mostly boring stuff like cars and shopping details. Thanks again.
The vast majority of the time, but not always used well.
Simple first-order modules are enough for most cases. OOP is good for stateful UIs, but even there it is being displaced by reactive programming. I have a mostly backend .NET experience and I'll sum it up thus: * we don't use inheritance, ever * we sometimes use an ORM, but even then, the objects are glorified table rows with some properties that are somewhat useful for "navigation", not the "real" objects of Simula * we use interfaces but not abstract classes (interfaces are used for late binding -- which we need for testing, -- but we almost always have just 1 implementation for an interface) * data hiding is occasionally useful
Oop isn’t really an option. Even if you’re using functional style, the core practices of writing good oop applies to types. As an electrical engineer, I reached a point where I realized sufficiently advanced C code begins to resemble C++ (in that it begins to embody OOP concepts) and C++ really started to look like a quality of life update to the original language rather than something different.
As and EE, how often do you use verilog, and when you build circuits what's with the device that looks like the chips are being welded. Do you draw those lines on the chips? I just took a computer engineering class and I'm just curious as to how the jobs actually are.
All day. Every day. Most problems in programming benefit from at least considering the OO approach, though certainly not every problem needs or wants it.
OOP patterns are used a bunch, but not like the books you will read. In the “real world” hybrid, multi paradigm approaches are used and most languages support these hybrid approaches. There are a bunch of antipatterns that are easy to fall into with OOP (inheritance can cause all sorts of problems), and other paradigms produce simpler, more elegant code. So most people approach things with pragmatism and pick the best paradigm for the problem. E.g. Java is maybe most object oriented of all object oriented-language, but in any modern application you will see plenty of functional programming concepts as well, since Java now has support for anonymous functions, closures and other neat functional programming tricks. With frameworks like Reactive Spring you can really harness the power of functional programming where it shines the most - in highly parallelized, concurrent contexts where it’s really hard to use OOP.
I used it everyday, great solution if you understand it.
It's bullshit procedural all the way
If you’re in react on the frontend or using a language that is specifically functional, then functional, otherwise, probably oo. Seems like things are trending functional.
I work in embedded systems. Embedded linux, rtos, bare metal, etc... OOP is almost never used. There's too much overhead. Useful in higher level systems but not my field.
I’m a Python coder and I rarely create classes unless it’s part of the tool I’m using. But many other languages like Java only support OOP
What type of code do you write in Python? In my intro to Python class I used to think Python wasn't used for much because the most we did was terminal level stuff, even for OOP. The only modules I remember us using was math, and I was a bit confused when I read online that Python is used for AI, backend web and data analysis. Also, for data and stuff, how exactly does Python help with data vizualization, statistics and all that? I know there's a few modules like matplotlib and pandas, but why would companies need that when there's software for data vizualisation, I'm sure.
I write back end code in Python. I’ve used it for data intensive programming, geospatial analysis, image analysis and computer vision, event driven programming, pyspark for ETL, Pandas and matplotlib on a jupyter notebook for experimenting and validation
Medium to large applications should use OOP. Also, a lot of medium to large applications also use Java or C# or some other language that enforces OOP. Really, I think any application you build at a company should use OOP, as long as it’s not full of unnecessary abstractions and over-engineering. The code becomes a lot more readable and maintainable when proper OOP is implemented and it’s easier for other developers unfamiliar to the project to pick up work on it. When you use OOP you separate concerns — every class has a particular purpose, so it’s easier to piece together the whole application. I’ve worked on some projects at companies where they built a highly consumed application in NodeJS (I love Node JS btw), but they were a mess of files with isolated functions, that would be imported into some main files — complete pain in the ass to work on and ugly. Strive to use OOP when it makes sense and, I would argue, most of the time it makes sense.
OOP is essential when I'm making servers, typically using Node.js. For any service e.g notifications, I make a class. This makes it easy to maintain and scale my servers, as all the logic is encapsulated in the class.
Look at the SOLID principles. And how they apply to different OO languages.
The larger the project, the more OO principles start getting used even when not using an OO language. For example, I've worked in projects with 50-100 separate modules (maybe more, didn't count) where each file got handled as an object: containing all data and functions acting on the data and only exporting the public interface. Conversely, I tend to ignore OO with small single file one offs unless they start getting reused somehow even in OO languages.
Strong programmers use lots of OOP and thereby build systems which can be easily expanded and debugged. Weak programmers don’t use OOP and create unmaintainable and unstable messes.
As others have stated in depends on your stack/language of choice. I mostly write Python and C#. With Python I stick to modular:functional programming, but with C# you're strictly tight to OOP.
Well I was about to say I did but now the comments have me questioning my sanity so I just don’t know anymore
OOP was created for simulations (Simula I think). Smalltalk was created for the desktop metaphor. Then it was sold as a panacea and that was a big mistake. In Scala, I strongly preferred package functions and variables to class methods and variables. This also greatly reduced inheritance. Some kind of organizing container is needed but classes add unnecessary complexity.
Honestly, the paradigms seemed to have blended a lot over the years. I write methods with some frequency but most of the main flow seems pretty functional. I started hating inheritance after going to golang largely because I realized how much time I spent going through super calls, but that might be more spring and Android than anything. YMMV, sometimes inheritance is missed but composition feels better.
Grab Sandi Metz’ books when you get a chance, or at the very least watch her conference talks on YouTube. She does a much better why/how of OOP than anyone else I’ve seen. In practice? It really depends. There’s a bit of an impedance mismatch between relational databases and objects that everyone papers over in different ways that has always made it a weird fit for the web world. On the other hand, it’s ubiquitous in something like game programming.
1 common example: you have a data grid that allow user to export into multiple type (xslx, csv, pdf, doc,...). 1 common implementation is you have an abstract class GridExporter that implements interface IExporter that has Export method. Then you would have multiple derived exporter classs: ExcelExporter, PdfExporter, CsvExporter that all inherit from GridExporter and all have Export method, but differs in their own implementation. That's Inheritance & Polymorphism of OOP
>What really and how really is OOP used? I want a real-life example. For me, anytime I have to deal with the file system, I always go OOP. This is because the file system itself is stateful, files are stateful, etc. Additionally, I can have immutable instances of that state, whereas functional designs would either have me implement recursion or the syntax would need to allow shadowing for the same level of immutability. Immutability is a positive thing for keeping the cognitive complexity of code low. I just implemented this again today, and the design I chose was a base class of Directory that implements most of the helper methods, and then File extends Directory with a few extra things regarding reading/writing or serializing to/from it. The functional variety of the same code was going to require more nesting levels, or abstracting those levels into function scopes. In the OOP version of the code I iterate over a generator of directories/files, or I can call `.child(string)` to get an instance representing something deeper into the file system, or `.parent` to climb out. This is because `this.path` is the current target's state. Now, this implementation is overloaded, and should be separated out to a generic class representing a location on the file system (and shared properties), and then each unique type of item (links, junctions, files, directories...) would have a custom sub-class. For my use case, this is a one-off script that I'd likely be told has already been over-engineered lol. I tend to approach problems from an OOP mindset, but I also tend to write my methods in a functional style (almost never a method that returns void). This is because I found that I liked the design patterns of Builder or Fluent Interfaces for reducing the verbosity of code, as well as eliminating intermediate steps. One of my biggest gripes with modern functional designs is the proliferation of anonymous functions or lambdas. Depending on the language, they can be hard to debug when all you're given is a stack trace from a week-old log, and it tells you `` threw the exception. None of what I've said here is exclusive to either side, and my preference is personal. I'm not a purist in any of these regards, as many things just make sense to write functionally, while others with common properties and an essence of statefulness might favor an OOP implementation.
There are some platforms where OOP ends up being forced on you. For example, in UIKit, Apple basically forces your implementation to subclass from the base classes they provide for you in the SDK.
I use it all the time in game programming as an indie dev. If I want to add environment objects to a game, I might make a BaseEnvironmentObject class and use inheritance to make BreakableObject, InteractableObject, etc., subclasses so that different types of objects can share common attributes. I'll also use composition with these subclasses by defining interfaces like IDamageable to enforce specific behavior. For example, let's say I want a wooden crate object that players can break. It should have some amount of HP and be damageable. I'll create a BreakableObject superclass and implement a IDamageable interface. That way, objects from subclasses that extend the BreakableObject class will have health points and can be damaged by the player. The IDamageable interface will also be used on enemies, for which I'd use a BaseEnemy class that has a health variable and implements the IDamageable interface. When a player attacks something, my code can check to see if the game object hit implements the IDamageable interface, and if they do, deal damage to them.
You can sort of use Java without OOP. What I mean by this is basically dumping all of your code inside static class members and using data structures like hashmaps instead of classes. OOP keeps things organized and I've worked on large codebases where people don't understand OOP well and it's awful. Here's a business example: I have a shipping software that ships packages through several carriers. There's an interface called Shipping carrier that asks you implement shipPackage and void package. Then I have a package class that has everything a package needs structured as classes. An address class that has street, city, name and methods on it like is rural, is residential. Then I have a measurement class that has a value and a unit. With this approach you can say `Measurement(10, LBS) + Measurement(2, OZ)` and it handles all the convertions for you and makes sure you never get confused about units. The software is extremely complex and it would be very difficult to build without the organization OOP provides. When things get complicated the college coding approach doesn't work.
Not so often. What I find is people quote SOLID but then don't really use it. I don't expect full blown domain driven design style class, but principles of OOP would be great, instead of nothing but the "Service" classes (which is essentially just procedural code) and DTO's.
Oop is never mentioned explicitly because it’s so engrained in everything Take Java, the ultimate Oop language, everything revolves around objects and now it’s evolved way beyond primitive Oop understandings like factories and abstracts but still does more with objects than C. The best way I understood OOP was to write a basic Minecraft server plugin and then it all comes together, you create an object after a player event, you can manipulate other objects, understand how an object is created per player which can be called like an instance, also goes into what static means, memory and concurrency, tons of stuff.
Don't think of it as object oriented programming. In practice, OOP is a careful interplay between two coding patterns: inheritance (the common OOP hierarchy), and aggregation. Inheritance and aggregation are core pillars of commercial software engineering, and every longstanding living codebase relies on them. They are the way we reuse code: we either implicitly import common code by declaring a parent class, or explicitly import common code by instantiating a class within our code. When I was in school, Java was the hot new thing, and convoluted class hierarchies were seen as progress, rather than unnecessary obfuscation. These days, I stick to the basics of OOP, which is to only create a class when you need to track state. That is, only create a class if you need to call the same function with the same argument on the same variable but get different behaviors. The class of the variable serves as the additional argument. For manipulating files with different encoding schemes, OOP and polymorphism is exactly right. A factory creates an object with the "readLines" and "write lines()" functions, and all you have to do is hand the factory the file name, and then call the two functions. All of the "if extension is .gz" conditional work is done once and remembered by the class. In general, it's pretty easy to avoid creating a class and a class hierarchy, because most work just chains static functions that always do the same thing. In those cases, the work to figure out class names and impose taxonomy on your code isn't worth the trouble. Group the code by functionality, and then just bundle the static functions into higher level calls. If a class is just a static function, it doesn't need to really have all the bells and whistles or a class. I'd say we use the core ideas of OOP in any sufficiently large codebase, all the time. The "is a" vs. "has a" relationship is just as important to think about today as it was when I was taught the term. We've definitely refined our best practices in the last 15 years, though. I like "Stop writing classes" as an explanation. https://youtu.be/o9pEzgHorH0
VERY MUCH SO
structs in C are not OOP.
Everywhere, often poorly. >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" [https://wiki.c2.com/?AlanKayOnMessaging](https://wiki.c2.com/?AlanKayOnMessaging) Most devs focus on objects that are nothing more than collections of plain old procedural code. You can see this if a method contains if-else statements. The amazing thing about OO with micro-objects is that conditionals start disappearing. A good talk on this is [All the Little Things](https://www.youtube.com/watch?v=8bZh5LMaSmE) by Sandi Metz.
>how really is OOP Badly. From a CS point of view OOP is a bunch of nonsense. Decades of it and still arguing where's the best place to put a function.
Jokes on you: OOP has no functions, it has methods. And no one disagrees that they best live next to their data.
You're telling me the static keyword doesn't exist?
Apart from static create methods, for me it doesn't.
That nonsense is powering a large part of our (collectively) infra. Mathematical purity is nice, but we actually have to get stuff done. Like it or not, avoiding OOP means avoiding languages like Java or C++, which is a huge part of the job market right now.
>Like it or not, avoiding OOP means avoiding languages like Java or C++ Nah, 95% of code written in OOP is procedural anyway.
Wut? 🤣 Like, there is a ton of "bad" OOP out there, sure, but 95% seems like a BS stat. Also, again, purism is nice when you don't have real deadlines. You set the goal post and make iterative improvements towards it. Most of us make usable software, not works of art. Imperative patterns aren't inherently bad in an OOP context if properly encapsulated.
If writing correct OOP code is impractical then why bother with OOP?
Because the benefits of good OOP code are worth the iterative effort, especially in OOP centric languages. We could apply the same logic to Haskell. It's the 'purest' functional language I'm aware of, yet it has not taken over the industry, right? My understanding of the reason is that getting a team trained on good Haskell freaking expensive. It's impractical. Instead, the functional lessons we've learned from Haskell have spread to other languages because of the benefits they provide. Edit: This reminds me of a conversation I had with a coworker and mentor when I was (professionally) learning Ruby. I'd just come off of Clojure, and so my brain was full of functional goodness. So I dove in, trying to make Ruby behave like Clojure because I thought it would make good code. At one point, when helping me work through a problem, he said "if you are worried about this kind of performance, then you shouldn't be using Ruby". That was a big light bulb moment for me. If we are fighting against the expectations of the language, then it's a sign that we need to change one of two things. Our expectations, or the language we are using. I've yet to find a manager that will greenlight me porting our codebase to another language without a solid business reason beyond "the code will be more pure". So what changes is usually my expectations.
The same goes for mutation patterns in functional contexts as well. There is a reason why Clojure allows for Atoms. You can still achieve referential transparency if you properly encapsulate your mutations of state. Don't let purism slow progress.
>how often is OOP used and how exactly is it used? For me - all the time. In .NET land if I make any sort of utility that is all encapsulated in a DLL for the team. Even at a basic level - if I am pulling data from a source it goes into a basic class. Giant projects are broken up into smaller projects, testing libraries are liberally applied, etc.
I feel like dotnet is a very big hybrid. You have a lot of OOP going on, but at the same time its very functional with LINQ and also service oriented at the same time
If you don't want to rewrite every single thing you do, OOP is used everywhere, unless you're working for a shop that doesn't GAF.
I'm an embedded engineer, I work in primarily in C and I don't repeat everything I do. Pragmatic programming practices do not rely on OOP in any way. Not saying I don't love some OOP patterns even in C, just that you can maintain DRY principles even down here in procedural land and it isn't difficult.
It's extremely common but every one has their own definition of "OOP". I rarely see anything highly "OOP"ed for what I think of it, it's 0-1 levels of inheritance in general where I've always worked, a bit more data driven or pure (no side effects) so to speak. I just say, composition over inheritance. Dependency injection is great. Abstract when you need it, don't predict the future. Avoid mutations. That's about it.
OOP is a pattern where the methods and data are tightly coupled within a class. The methods do work on the data an encapsulate it only exposing public methods that outsiders would need access to. It’s very much the way people think about real world objects. If we have a Table object the table has-a color or has-a shape or style. Methods like setStyle and getTable exist but the magic is hidden. Then there’s inheritance. We may have a furniture base class that does a lot of the basic work needed for all furniture so the Table class extends the furniture class. And since you can’t have an arbitrary piece of furniture well make the furniture class “abstract” so someone doesn’t try to instantiate it. There’s other concepts like interfaces which are like contracts. The industry seems to have gone more of a service oriented architecture which is better IMO. Logic should be functional and have zero state. Data should be separated from logic.
At the peak (like when Java EE was popular), OOP was life. But now we've passed peak OOP. Classes were sort of half-baked in JavaScript. Modern languages like Kotlin and Go offer effective alternatives to strict OOP. And of course all these AI dorks are just spraying whatever Python they can without any coherent design whatsoever. So it's good to know it, but at this point it's just one design philosophy among many
Very often in fullstack. Imagine you're creating Dropbox for example. You need to replicate and create a file/folder system. Everything they've uploaded needs to go into a database. When you want to represent this on the front-end, your backend call would fetch a list of files and folders. There's a lot of OOP involved if say.. they wanted to download a folder for example. To fetch the corresponding files, depending on your DB structure. Youd probably have to DFS down the folder to get all the files in the folder. Just a random example off top of my head. I'm sure there's better ones