The Problem with Object-Oriented Programming
Vložit
- čas přidán 6. 01. 2024
- 🚀 neetcode.io/ - A better way to prepare for Coding Interviews
Clip from the video: • Jonathan Blow on the P...
I stream on my main YT channel: @NeetCode
🧑💼 LinkedIn: / navdeep-singh-3aaa14161
🐦 Twitter: / neetcode1
#neetcode #leetcode #python
OMG so true! This drives me nuts in my C++ job! Every time I want to figure out what is happening I have to go up and down the inheritance/interface tree. Nothing does anything. After 3-4 jumps I don't even know what I am looking for.
Alright, then you realized let's say there is no actual implementation in this dependency tree. Great. You search for all classes that implement the interface in question. Excellent, they all do something different. Now you have to find that the piece of code you were originally looking at which implementation was used in the background. But then you can easily find yourself in the same cycle, trying to find what implementation actually got there. Madness.
Even worst when you have interfaces prematurely. There is only a single implementation yet, I need to jump to extra hoops, because we designed the system.
Yes, I get frustrated with this at my job too. I use my debugger to automate searching through interface layers more than I use it to actually debug something.
The funny thing is the same people who write this dynamic dispatch spaghetti garbage when asked if goto is bad they’ll say yes.
This has been my experience with a lot of OOP codebases! Even some I wrote myself and revisited after a few years.
I subscribe to what you said, true, totally true.
And i'll add :
when you have to reverse engineer a binary of which you don't have the source code, you can see pretty soon if it was written using OO because nothing does anything, and the cpu just sits there doing function calls and shoveling data arround for nothing, and after a few hundred cycles it actually does something ( like a sum, or a xor or , you know ...something usefull, the actual computation )
Or when the control flow just disappears into nothing, because the function to be called is computed at runtime...
Then we complain that damn word.exe barely opens on a 24 core machine, and when you write, the letters lag behind your typing speed and stuff like that.
break points , epic bruh moment
The problem is people focus too much on one paradigm. Objects are great, but everything doesn't have to start by inheriting a purely abstract class etc.
I second this! That's the point!
"Objects are great..." [Citation needed]
The problem with generalities like that are they don't always apply. Even worse I've yet to see a time where an OO object is great vs simply using a `struct`. Unless you just mean `struct`s with pure data are great?
@@totheknee Citation needed? I said it, you're quoting me.
You're argument is like me saying, "hammers are great" and you being like "not always!"
For what objects can do they're great. Being great doesn't mean it's great for everything. If you don't understand basic logic like that then you need not be programming anything my friend.
Especially when i preface that with "people focus too much on one paradigm" lol trying to figure if you're a fail troll or what
Well, yes, for the most part.
You can stick to your abstract way of life and introduce a little bit of composition. Do like PHP does.
Lmao useless shit
I’ve worked with too many people who can’t even explain code they wrote four weeks ago because everything is abstracted away behind services, factories and interfaces that do nothing but juggle data around in the most convoluted way possible. Everything is “maximally reusable” but never gets reused.
And then the desire to wrap SQL which is very well readable in massive “builders” where you have no chance to quickly check what SQL is actually being executed.
The point is to not have to read the raw SQL. Why you would ever want to do that beyond performance analysis is beyond me. In fact, its advisable to do this for security reasons so you dont make injection attacks easy.
And I honestly cant think of how you would even construct an OO architecture without reuse. Its practically impossible unless you absolutely suck at understanding it.
Factories make sense because they allow you to do things in a more flexible way. For example, Ive used factories for building database connection strings. Doing this makes it stupid easy to add connections to new DBMS or even different file types. Most people think supporting multiple DBMS is a waste of time, but it's not uncommon to need to switch between multiple ones, such as Access and MSSQL for example.
I hate when engineers starts to implement design patterns without an actual need. The codebase isn’t even got any bigger yet. And instead of building a momentum to ship product faster, they stuck arguing what design pattern should be used to make it future proof.
Yes and then the project requirements completely change lol. And people hate on high level language and quick shipping approaches…
@@DEBO5
Sure, but that is exactly the problem. You don't know what the requirements are going to change to, or even *if* they are going to change at all.
There is this deeply rooted fear of throwing away code and just building from scratch. The people who love their abstractions deal with it by building these overly general abstractions, where a simple if statement or switch might have sufficed and been clearer.
The people who dislike abstractions deal with it by writing giant modules of spaghetti code, that you need to be inanimately familiar with in order to maintain, instead of just using a bit of dynamic dispatch or a well known pattern.
The former wastes incredible amounts of time building their tower of abstractions for things that could have been simple and the latter wastes incredible amounts of time maintaining their brittle code because it got more complex than they thought.
Both lead to code that is incredibly hard to read and reason about. The non-abstracted code, because you've strands of spaghetti going off in all directions and the abstracted code, because now you need to familiarize yourself with the tower of babble that was dumped on you.
The point isn't to avoid design patterns and abstractions, it's to avoid their premature usage. Ideally, the the code should always be the simplest code that deals with the actual problem.
Implement that code and if at any point you notice that your simple code stops being simple, tear it down and write code that uses the abstractions and patterns that are actually applicable to the new requirements. But don't start off moulding your code to some distant fantasy requirements that may never materialize. You're going to waste a lot of time writing abstractions that are utterly unnecessary.
Design patterns are one the biggest distractions in dev. Just write the code that's needed already.
I hate it too but in my experience you better implement the pattern early unless you want to spend a lot of time refactoring.
design patterns are applied to solve certain problems. if you apply a pattern without solving a priblem then it is an antipattern
I think this was the biggest mental hurdle I had to overcome when I started programming. I was basically learning how to conform to this weird standard. I also think that's why I appreciate functional programming so much because you get to solving problems a lot faster
That being said, I do think OOP has a place. I don't see why it's bad that we have industry standards in an industry. It gets out of hand at times, sure, but I'd rather have guidelines for everyone to follow rather than everyone doing their own thing
Doing an own thing is good if it's a good thing. But the programming society is not uniform: some are better educated, some have stronger common sense and measure than the others, etc. I've seen a recent interview with Dave Cutler - can't imagine a person like him following standards. He is the one who defines them.
"I don't see why it's bad that we have industry standards in an industry"
Plainly, I'd say standards are good. But OOP isn't a standard, it's more of a philosophy or a paradigm on how to structure code. Most people don't do OOP, even the ones that do doesn't mean they do it "right", there's plenty of ways OOP codebases can differ, there's usually unwritten conventions for a particular codebase. We have some standards that work and are followed, like for example TCP, but as a whole this industry is a mess.
@@thrashwerk
I’m confused. Is OOP just the practice of putting everything in a class? Or is OOP using classes in any capacity?
I'm done with people oposing fucntional programming to oop, as if you couldn't go stream.filter.foreach.toarray in java
it is a problem the same way agile and scrum and all this shit is a problem: you are paying for illusion of efficiency with actual efficiency.
I could not be a problem, but it is. Truth is, interfaces in Spring help you inject or override code from module to module, but there's nothing about OOP in that, its just Java. If you are writing an interface of an abstract class of the class you need but wouldn't need if java didnt enforce objectifying because you think it is the correct thing to do (and a lot of people do) then we have a problem
OOP is okay. Over abstraction is not.
5:40 - Being honest here: please don't mix up the term "premature optimization" with "premature overengineering." Reason being that almost no one these days seem to know what optimization even means, and they just repeat what they hear without understanding. It's so bad that some (most?) programmers these days think that simply avoiding writing slow code in the first place is "premature optimization." For example, if I avoid a triple nested loop and just use a single constant instead, someone will jump down my throat and say I'm "prematurely optimizing" when in reality I just didn't need a triple nested loop. It's almost as if they think we _need_ triple nested loops everywhere, and then we remove them at the end of production in the mythical "optimization phase."
Premature optimization is the overengineering of solutions related specifically to performance.
Having grappled with abstraction, SOLID and design patterns for over 20 years all I can say is Hallelujah.
I can't tell you how often I've had to think "wtaf does open for extension and closed for modification really mean and do I really need to follow this rule in the age of modern refactoring tools?". The worm is turning. Over abstracted code is an absolute mindfuck.
I started to push back on pointless abstractions on PR's a while back. OOP and it's rules were a best guess of how it should work at a certain point of time. We've seen the results. Pretty horrible. And as for "clean code". Omfg. Ten shitty 3 line methods does not make code easier to read than one 30 line method.
"And as for "clean code". Omfg. Ten shitty 3 line methods does not make code easier to read than one 30 line method."
Thank you! I repeat this to no end, but the message does not seem to stick. There is a religious fervor to which "clean code" is applied in some circles that bothers me sometimes.
Don't tell the POOPs (professional OOP'ers) that I write 1000 line functions
;)
If you don't know what that means, then I can understand why you'd be frustrated.
What's "that"? Which specific point are you referring to?
You're using it right. Abstraction inherently isn't bad (it's obviously what a lot of coding is about), but when you abstract, you start putting up walls and sometimes it's hard to couple those abstractions together in order to work together the right way. So it can be bad to unnecessarily create abstractions before you need them because you end up spending your time connecting them together in the right why and it ultimately makes your code less dynamic.
EDIT: I don't know why everyone has to have a moral judgement on everything. It's a tool in your toolbox, use it at your will. If you don't think you need, don't use it.
If only I live in a world where I don't have to deal with someone else codebase.
Paradigms are not tools, that is a complete nonsense take. And there's not moral argument on Jon's part
The characteristics/parts of OOP are tools. Yes in a purity sense, treating a paradigm like a religion is what I mean. And yeah I wouldn't say he's making a "moral" argument, I mean it in a more figurative way. I'm not sure what the word I want to use is. All I'm saying is it doesn't have to be all or nothing.@@marcs9451
Regarding Alan Kay's definition of OOP:
As I understand it his idea was very similar to what we call today "actor model" or "actor-based concurrency", which is the core concept behind the language Erlang. The idea is to have "objects"/"actors" that only communicate via messages instead of direct method calls, and just react to messages they receive. Software built like this is very easy to distribute across multiple CPU cores or even devices as the program itself doesn't need to concern itself with how the messages are actually transmitted. It also reduces coupling to a point individual actors can be restarted after a crash without affecting any other part of the program, the worst that can happen are some lost messages. Erlang was designed by a telecommunication company (Ericsson) for minimal downtime of their systems, and this actor-based model allows live updates as well as crash recovery without any downtime. It's so good at what it does that many modern messaging services (e.g. Discord) still use Erlang in the backend.
The difference is that in Kay model messages are asynchronous, in the later and simpler models they're synchronous. It's not that much of a difference on the system design level.
discord uses elixir, not erlang
@@marusdod3685 Elixir is a syntax sugar on top of Erlang. Sort of.
@@marusdod3685 Ok. Though Elixir uses Erlang's VM, so it's the same idea.
Although, I agree that generally pre-mature abstraction is bad (that it negatively affects developer productivity) and that quite a lot of organizations like to "abstract" things out to make the code more maintainable and extensible without the need for it, I would, however, like to visit your point about - "code that perfectly solves the problem with some SOLID principle violations". I think we, as engineers, should understand that the problem you are trying to solve is a constantly changing goal-post. If you solve perfectly solve problem A right now even with bad code, you will then probably need to solve problem B, followed by problems C and D. This is a very likely scenario in all (big and small) organizations. That is when writing code with abstraction shines and is very much needed. Understanding the balance of how much abstraction your code needs is what you, as an engineer, should decide. If you over-abstract too soon, or if you do not abstract at all - both these scenarios will bite the engineer later. OOP/Abstraction is not the problem, but a tool, and we should not overutilize it or shy away from it.
abstraction doesn't require OOP though. OOP is a cult mentality, a belief in some mythical 'clean code' standard.
@@drygordspellweaver8761OOP is a paradigm. What you’re talking about is people that think something is true without reason (which I think equating OOP to a cult falls under). There are people who do this for every paradigm. These are all just approaches that organically arose to solve problems. Sometimes approaches are supplanted, sometimes they remain valuable for certain problems. I haven’t seen any compelling evidence that OOP no longer has value for all problem spaces.
> to make the code more maintainable...without the need for it
That statement is self-contradictory.
The point is that you can abstract it later, if you really really need it in order to ship your project. In reality, most of the time you don't need that abstraction, even in company working with team. You just need to ship project, earn some profit and than decide, do you really need to abstract something, will it solve the bug tracking problem, or testing problem or team productivity problem. You should analyze it later, it will safe your time, your mental health, your motivation to stick with project and team.
These tidbits of information have persisted from among the elder members of the programming community, they are exceptionally valid here. Abstractions should be useful, classes are abstractions. Prefer the free function unless you have something you actually need to encapsulate. There is nothing wrong with accessing a class/struct data member without getters/setters if you don't need them.
these insights are pretty informative, keep it coming!
loving this typa content
OOP is totally fine and in fact very similar to imperative if you don't use inheritance. After all, there's little difference between data.doThing() and doThing(data). I think one of the biggest problems with OO is trying to reuse code through inheritance, which usually gets really messy and unmaintainable. If you have clear separation of data, logic, and presentation (not OO-specific recommendations) and avoid pointless abstraction, OO can be great.
I would absolutely avoid virtual mapping. Because, why introduce some indirection when you can allow the computer to get it directly?
Inheritance turns out to be very useful if you want to enforce unit type correctness in Physic. Like a function that take Radian and you pass in a Degree and it gets converted at compile time to radian. And give error if you try passing in float for instance. You do something similar for glm::vec3. Like Point and Direction both use vec3, but, are not the same.
It is meant to be used as correct enforcement tool.
The idea is not to stray too far from basic. Don't adopt just one paradigm.
No, because data.doThing() takes a whole lot of extra boiletplate underneathe the hood. OOP is atrociously slow on top of adding complexity for the sake of hiding data.
@@drygordspellweaver8761doThing(data) data.doThing() is exactly the same as far as the compiler is concerned.
@@drygordspellweaver8761 data.doThing() and doThing(data) is exactly the same as far as the compiler is concerned.
This idea that OOP is slow is actually incorrect.
What truly matters is how the data is laid out and how it's being used.
OOP class stores data in interleaved form. So if you just wanted an array of position you need to separate them from the other so it doesn't "pollute" the cache line with information that isn't position if all you wanted was position.
Yet. Interleaved data is also beneficial in it's own way when you do in fact use all of the stuff in one place that was in it to reduce jumping around memory.
It is a tool. None else.
If all you have is a Hammer everything is a nail. So, use everything that works well for the task at hand.
Exactly! Stay away from inheritance except for inheriting types for increasing readability(You know, declare an abstract class Vehicle that does nothing and then make classes like Cars, Motorcycle, Airplane, etc inherit from Vehicle. This does not break your code and helps later on if you just want to do an operation on any kind of vehicle without writing 10 if statements. Later on you can add the common abstract method to the Vehicle class and implement it in your sub classes). Other than that don't overuse inheritance. Go with composition.
If the solution is complicated, you’re doing it wrong. The purpose of abstractions is to simplify the work. Writing macro assembly code is easier than machine code. Writing C is easier than assembly.
OOP is easier than procedural code because it abstracts (hides/encapsulates) the details that aren’t a primary concern of the problem you’re solving. Iterating thru loops. State variables and if statements. Switches and cases. Code duplication. OOP just makes it easier to build apps and make changes later on.
Object orientation’s classes and encapsulation are architectural mechanisms. That is, they provide ways for a programmer to organize the code and data as they choose. OOP languages do not dictate how code and data are structured, they just enforce the access to them.
When you use the object orientation facilities correctly it makes it easier to read and understand code. If you write procedural code in an object oriented language, it’s going to get complicated and ugly in a hurry. If you treat variables like data containers that are processed in a client function, your code will be unwieldy and hard to understand. If you put functions and classes into a hierarchy of abstractions because of a theoretical model instead of the problem you’re trying to solve, your code will be hard to find.
A binary search tree can be used to hold a string. But traversing and manipulating the string would be unnecessarily complicated, don’t you think?
I think the main take away is that only HUMANS care about objects. It's more in line with how we model the environments around us. But an "object" from our heads can only ever be _grafted onto_ problems in computer space. I think OO offers itself really well to situations where there is a real-world system already in place that your program is modeling and "objects" in your code line up with actual real objects in that system. It's also pretty good for setting up guide rails for other developers, but if those guide rails are bad then new devs will inherit bad practices.
For solving a single well-defined problem, I think sticking with procedural programming is the way to go. Starting with OO will cause you to set up arbitrary walls to stay confined in when you should just be focusing on raw problem solving. Procedural lets your solution change shape at will so you can really explore the problem space.
Agreed. I frequently will solve a problem procedurally first, because I found that trying to make it OO from the start resulted in lots of time wasted as I learned more about how to solve the problem I was working on.
Also, in the real world, not everything is an object. Some things are concepts.
This feels like a strawman but I'm not smart enough to say why. Functional and OOP are different tools to solve different problems. Being dogmatic about one or the other being better for everything doesn't really make sense. For example the main programming I do is ETL. It's more important for me to turn solutions around quickly than to get closer to the hardware. Different problems require different solutions.
On the other hand, there's the old saw: "There is no problem in computer science that can't be solved using another level of indirection." I remember once trying to program a calculator using only instance variables. How much easier it is to solve a problem like this with the appropriate data structure. Once you have data structures, I think you're starting to move towards OOP.
There's another book I read a bit of called "The Philosphy of Software Design". One refreshing aspect of that book was the author's focus on complexity -- the central problem in software design is supposed to be to minimize complexity. Sometimes all the cruft of OOP increases complexity. Indirection itself is a form of complexity. A hierarchical page table is harder to understand than a simple page table, and a simple page table is harder to understand than a giant array that makes no distinction between physical and virtual memory addresses. But you get so much power out of separating the physical location in which a piece of memory resides from the system you use to identify that physical location!
The difficult thing is developing the foresight to know when making something more complicated in the short run could help to make things simpler in the long run. Sometimes you can get the worst of both worlds, obviously.
True! There's also a mantra to not over engineer and to prematurely abstract.
So you should decide when to abstract and in that case you knew it needed to.
John Ousterhout!! Great book
enjoying the react content :)
There is a HUGE misunderstanding about the Dependency Inversion Principle.
It indeed says to rely on abstractions rather than implementations.
But that's only the second part of the principle.
If you apply only this part, it will lead to code that is too abstract and unmaintainable.
The key is the first part that says : High Level Code (business/domain) should not depend on Low Level Code (details), both should depend on abstractions.
That is, separating only the low-level concerns (Persistence, UI...) from the high-level policies (Use cases, Domain Model).
That's the core of Hexagonal Architecture / Clean Architecture, and what I teach to my students.
With the notable benefit of being able to test your Domain Model independently from the low-level technical concerns.
And being able to swap out your ORM/Database Engine if necessary.
And being able to run your code locally or inside an airplane with no internet access, since the gist of your code is implementation independant.
The only caveat is how your code is a little bit more difficult to navigate because from your domain model point of view, you can't know which implementation will be called.
In practice you rarely have more than two implementations (in memory & concrete) so it's seldom a problem.
That's a good trade given all the benefits you gain (testability, reusability...).
I agree. You’re supposed to identify seams in your application. This lets you focus on what’s important-your domain model.
The idea of domain layer is very weird to me. I would rather architect the program just simply with UI/Presentation layer and Business/Backend layer. You don't need more layers. Its much easier to add integration changes, add few queries to database or rest service or to low level api.
What kind of data structure are you using then?
It sounds like the real problem is the way dependency injection is used than object oriented programming. I enjoy object oriented programming. I HATE the way some developers not only over use DI but throw in the mediator pattern breaking all my tools for discovering code. I’m a software architect and I read A LOT of code. It’s such a pain.
How does one overuse DI? I am assuming you mean dependency inversion. Also why do you have tools for discovering code?
@@skyhappy I use “tools” in the sense of techniques. Often times in Visual Studio you can use features like “Find all References” to see how a function or class is used within a project. Dependency injection can break this to a degree.
@@brianm6965do you mean dependency inversion? That's when classes only implement interfaces. I used the same find all references tool in Visual Studio and also had to find implementations a bit painfully this way.
@@brianm6965I use DI in VS and have no problem with the IDE resolving compile time references. Don’t really understand what you don’t like about it; I follow the principles in “Dependency Injection in .NET” and find it lends itself to writing more loosely coupled code that’s more testable and the object graph is very easy to understand. Wondering if you’ve worked with it where people abuse it (resolving things front the container all over the place instead of using constructor injection)?
01:10 I love Jonathan Blow, and have been a huge fan since Braid. I own a copy of The Witness, and keenly follow his thoughts and updates on Twitter and CZcams and wherever else he gives talks.
But, really, as someone who studied PL Theory and the history and origin and (most importantly) the CONTEXT in which programming languages were developed, I stopped watching at this moment.
"... solve problems in the *_best_* way", really? No. Alan Kay never made this claim, regardless of SmallTalk. No one ever made this claim. You have Functional and OO languages, and Imperative and Logic-based languages like Prolog. They all solve something different, and evolved in extremely different contexts.
Having used OO in many industry projects today (while also diving into other programming paradigms), I can assure you, the subset of problems and the scenarios in which OO is supposed to be used, it definitely does its job very well there.
So I just started learning OOP and so far I really like it. I think issues with it arise when you turn every little thing into a class, similar to how "clean code" says that if a function/method does more than one thing it should be refactored into another function, which is absolute madness. OOP is essentially just building a program out of bricks, but some people go too far and break the bricks down into gravel, and some even break it down into sand. Even the book where it's only lightly touching on OOP paradigms (it's for a specific language, not OOP) goes too far imo... there are parts where it suggests making an object for what should just be code executing in the main program entry point for example.
I've also only just barely learned about inheritance and I can already see that being a nightmare if you don't really use restraint and only use it where it saves you from writing pages of boilerplate. Basically OOP seems like a very, very good model for breaking down programs, avoiding global state, and protecting code from other code while still allowing the pieces to interact, but it also seems very easy to go overboard with.
Inheritance should be largely avoided. Use Interfaces instead of inheritance. OOP is very good when you have very large programs that you're working on over years. Take an enterprise company with 1 million lines of code and you'll be glad its all ordered out the way it is. The first time you open a class and find it does...everything with functions that do...everything, you'll understand.
@@jasonwismer2670 Inheritance should not be avoided, it should be used appropriately. It's really tiring hearing this dogma.
Instead of using C to manipulate the sand directly with glue
@@chudchadanstudagreed but it is commonly abused and can easily make code more confusing. Sometimes it’s clear it’s the right choice but I think “preferring composition over inheritance” is not a bad general rule
@chudchadanstud learned the hard way that yeah Inheritance should be avoided.
It's not dogma but just experience from its pain.
prefer composition instead.
Good abstractions take lots of time, attention, vision, case study, prototyping and testing to make. When done well, they can survive generational change in technology. A great example of this is a core protocol such as HTTP, which I don't think would be a stretch to liken to a plain text OO interface.
I think lots of people, myself included, had dreams of their code living forever and only being built on top of because we saw the success of some legendary early abstractions. But in reality, my procedural code from the 90's outlived OOP code I wrote much later, simply because I was not able to come up with high quality models several times a day every day, and bad assumptions would just pile up.
These days I lost all shame to do everything in procedural spaghetti first, and factor things out on first reuse. This way most of it naturally coalesces into a hierarchy of objects, and the stuff that doesn't is obviously not doing anything worth abstracting. So I can either completely forget that it exists, or if it has a bug, I enjoy the benefit of fixing a flat page of code that contains most of the context of the problem, that's usually very generously commented because I was relaxed and grooving hands on with a fun problem when I wrote it.
Bro where are you doing this livestreams ? I wanna be the part of it. Please send us notifications or something before you have these livestreams.
I find oop harder to reason about. Modules are great, and I think it's helpful to tuck away the squiggly bits, so that the flow and logic is easier to follow.
Strange how all the "leetcode" and google / facebook interview experts suddenly can't understand abstraction.
Sounds like you're upset about something.
@@NeetCodeIO Nice of you to recognice it. YES! I have a BIG PROBLEM with idiots that says there is a problem with OOP. These people never succeeded in understanding OOP and now they are trying do diminish others that masters it. For some reason these people thinks that IF OOP exists THEN EVERYTHING must be programmed using OOP. They've probably found their small new tool (like kotlin, rust, python) and thinks EVERYTHING should be programmed using their favorite tool / programming style. These are the same people that thinks enforcing code styles made for cramming info into textbooks is a good idea for real production code. What happened to picking up the tool that suits the task at hand? If OOP is the better choice - then use it. If the task doesn't require OOP then don't use it. Why the hell is this even controversial?
OOP is just a way of organizing your programming work. It helps you think about the problem and constrains you into a certain set of work patterns to help minimize errors. It also can help to manage complexity in a project better.
Yes, OOP can be done badly (bad code and bad design are things), and a lot of the abstraction and modeling tools it provides may be overkill or just a worse fit for some projects.
Personally, I don't have a huge issue locating implementations in OOP code, so I don't get this argument, but maybe I'm privileged somehow.
Most of the armchair critics of OOP are those that seem to never have got to work on a codebase that properly implemented OOP.
It's like those women who say "all men are pigs" after their 5th breakup
@@AAZinvicto This is exactly what I was thinking. I mean, obviously, different tools for different problems. Use what is appropriate, but don't complain about what you don't understand. I have a anger/disgust reaction to 800-liine methods.
@@AAZinvicto I worked for many different companies. The thing is, something like properly implemented OOP doesn't really exist. What does properly implemented OOP even mean?
OOP is just one example of messy code. I've seen people doing functions only and they still hide the implementations deep down the code base. Like you have to go trace lots of function call in order to reach the actual thing and read it.
That isn't really an issue even if you have to go 100 levels deep if you can for sure trace it. Issue comes with Dependency Injection. You don't know where to find the actual implementation with Dependency Injection!
@@arpitkumar4525 Dependency Injection feels like magic fr
I do not see any problems with OOP after 20 years of programming using it. It simplifies huge projects and hides unnecessary code details inside the classes. You do not need to know details, use properties and methods of objects. And it is also more easy to support and extend your software.
People whining about how 'x' programming paradigm is bad are just identifying themselves as amateurs. If you are working with any Turing Complete language (paradigm), then you are able to commit any number of atrocities, which makes them all "bad", or "problematic".
The problem is further exacerbated when you are working in a large codebase and you’re forced to solve a problem that exists because the original design of the class didn’t know all messed up ways programmers are going to use the class down the road. Solving the problem becomes exponentially harder because you can’t just go into the core code and start modifying abstract classes fields and instead you have to hack your way around the structure in place and potentially making it even more confusing because now you’re extending the class and casting objects as your new class. It can get messy for sure. The joys of programming.
What you describe is not unique to OOP.
@@NathanTenney OOP makes it harder to change things
@@NathanTenney True but solving it the OOP way makes it 10x harder than say doing it functionally for example. That was OPs main point.
What you're describing is a situation where someone DIDN'T follow OOP principles. The programmer violated the very first principle, which exists specifically to address this situation.
OOP makes everything more maze-like. Having to open 3 to 4 different files to find the actual implementation.
As opposed to not using OOP and scrolling through endless lines of code.
Either way it’s bad. The only way is to get familiar with the specific source code.
It isn’t bad with an IDE which has Code Searching / navigation. But without the right editor, it’s impossible.
Scrolling through code in something like OpenGrok or GitHub sucks for that reason. You can’t actually jump through the code and follow how it’s executing.
With oop, you do both
Faulty system design is used as a critique for OOP.
He is right yes. Even if you manage to define a good abstraction it still took you energy to do so. It's like those pagination algorithms that computers use: the threshold at which they are worth it is when they work 90% of the times, and they work 92, but for object oriented programming most of the times you are adding cognitive overhead as well as actual overhead.
OOP can be good but you always need to ask yourself if you are being organized or just fancy. Ask it constantly, and never get used to just being fancy.
The mental decline of programmers is kinda like that meme of hard times -> strong men -> good times -> weak men -> hard times. Home computers made excellent programmers who actually knew what they were doing, because of the hardware limitations. Then computers got (too) fast and this whole fiction of "zero cost abstractions" came about. Fast foward to current year and modern programmers don't know the memory layout, in part because of the myriad of dependencies in their application.
At some point the whole thing will crash, because it's too complex to maintain and understand. Also energy costs will soar (just think about the utterly insane energy consumption of GPUs en masse with things like GPT training), which will force more efficient code out of people.
Man, it's refreshing to hear this, just solve the damn problem :)
I like it, keep it simple, know what is needed.
Dont write everything oop, know when you need to write oop.
Just write to make it work and is testable.
If you start with the test, it help you just to satisfy the tests, and dont write more.
If you start with the code, you try to think about everything.
When i start with TDD, i also switched to move from oop to more simple code that is functional.
The problem with OOP (the classes, objects, inheritance kind) is that it relies on building these taxonomies of entities regardless of whether it makes sense in your particular problem. And not only creating them, but also getting them right from the get-go.
Oh I hate speculative abstraction!
You do realise you can simply remove them right and no one is forcing you do add them?
@@chudchadanstud Good luck not introducing refactoring bugs without a strong and precise type system
@@mskiptr That's what unit testing is for. No lang will save you from bugs due to refactoring.
@@chudchadanstud Sure tests are important, but they catch bugs only in the behavior you thought of. In contrast, if your data types reflect what you're modelling precisely, the compiler will point out every spot where you forgot to handle a case or where things no longer match up.
And that reminds me of another point: including hidden state in your objects obliterates property-based testing. Such a shame, since that is _the easiest_ way of comprehensively testing your functions.
@@mskiptr I don't get it. What makes you think OOP isn't strongly typed?
Introducing bools and ints for error handling literally creates the same problem you just described. It's called Primitive Obsession.
Like I said, there is nothing that will save you from refactoring bugs besides tests. Bugs during refactoring are a given.
Why are people trying to run away from their responsibilities as programmers?
OOP is just meant to organise your code properly and hence your code becomes more maintainable. There can be unnecessary abstraction but its defintely a great principle to follow for larger projects
Don't fall into the trap of thinking that OOP is just classes with methods in them. OOP is a much bigger paradigm than organising code into structures that make sense. No-one in the world has issue with the organisation part of OOP. It's the inheritance models and patterns that most people have issues with because they force you into a structure that you'll need to reorganize, sometimes extensively, just to add something new that you hadn't planned for. By its very nature, strict OOP actually makes your code LESS maintainable because making changes to the structure becomes much harder when you've got 50 tiny classes all inheriting from each other and another 20 factories generating instances of those classes.
This is why injection, interfaces and composition are often considered a better way to do things.
You can write (probably even better maintainable code) using strict procedural programming. I have seen a hell of lot more maintainable C, assembly and Pascal code than anything OOP. With procedural languages you need to be aware to separate code from data (they aren't one and the same thing and bundling them is just very inconsistent.
It makes more sense to have a structure and a file and/or lib that holds all functions that can process the data in that struct.
The problem also with OO becomes that in more abstract or technical cases it's not really clear what an object hierarchy should be and it gets very hard to take a guess where something is.
There's a reason that heavy OO is on it's retreat with new(er) languages like Rust which is a arguably a very lean OO without subclassing, Jai, Go, Odin and Zig.
Like Linus said, Linux is in C not C++ because is better and keeps away C++ programmers. Feels better to work with types.
@@ilmanti Most people think of OOP in terms of Inheritance exclusively, but Uncle Bob said to favor Composition over Inheritance. He's right too.
The point of using OOP or any set of "beliefs" is that you get to structure everything in a way that makes sense even if it's tedious, which will make large projects manageable. Have fun writing code with low abstraction and feeling smart, but don't forget you'll need to rewrite when there's more code to deal with.
Cope lol
I agree here. I don't know what the target audience of this channel is but apparently not people who write business applications. I have the issues with abstractions as well but if you reach a certain level of complexity they are necessary, otherwise you will just have only messy spaghetti code at the end of the day which can't be changed any more.
@@mudi2000a Exactly. People here are probably at that level where they kill both the code's flexibility and readability to get rid of 20 lines of code and think they are smart for doing so.
I just started learning programming starting with C# a couple years ago, so my thoughts may not mean anything, but this the same thing I thought. I've looked at the non Object oriented languages, and I definitely like the structure that OOP provides 🤷♂️. I also understand the issues people mention throughout the comments, but that's where good documentation comes into play. And there's usually a tool for something. At least that's what I figure from everything I've read and listened to and watched. Haven't built any big applications yet
@@GloriousMightykarpYup, I see so many videos like this (I think at this point the algorithm has picked up I mean being triggered by them lol). In my experience some people saying these kinds of things are really good, so you can’t completely discount them, but they are overly dogmatic. Then you have a bunch of inexperienced people lapping it up. The more you work with abstraction and techniques that manage complexity in large code bases the easier they become to understand, and the more you appreciate the problems they solve. Are you really going to say someone like Martin Fowler, doesn’t know what they’re talking about?
You should also mention improved testability by using those principals especially for unit testing and mocking
The process of learning to be effective using OOP is releasing that everything he just said is either irrelevant or just plain ol' bullshit.
I could only reuse one of my own class files (ie perl, python, java) as a SysEng if it were ultra simple. And it also had to be very generic. But I'd still copy it to another filename. And import/use that alternate copy just in case it didn't quite fit the bill. In addition, inheritance is always a bad idea. Unfortunately, it's the first topic taught in howto books and college lectures.
Simula was invented in 1967, and Smalltalk in 1972 -- well before the 80's.
In theory, once you have the right abstractions, it's only a few lines to solve the problem.
But by all means, every programmer should find his/her own way of working.
I can fulfill today's requirements directly, but they get massive, interdependent, and ever-changing.
I use abstractions and OOP to encapsulate that mess.
When I started my current job, I was adding features, but my pull requests had huge net LOC reduction.
We joked that at this rate we'll finish the project with zero code.
Abstraction is a good concept in moderation. It is valuable but if you create too abstract of a hierarchy, for example, then you may not be able to fix problems because you don't see what is under the hood and when you take a look you better hope to God that you didn't create a fine spaghetti that you now have to wade through.
I started programming learning C and writing simple libraries from scratch and the feeling of learning what happens under the hood, why my code segfaulted and understanding how a language is used to write itself😮. Then I switched to Java 😂 and now I think I am not learning programming but simply throwing libraries over libraries and libraries....
Layers of Abstractions :
Assembly, Bytecode, Java Code, Oops, Interfaces, JDBC, JPA, Hibernate... I don't understand what is happening under the hood. You learn a library then next year it changes its internal structure. Now you have to relearn the same library. Most Developers spend their most time trying to understand libraries.
Remove the library... Most developers will simply crumble.
Are you in school or working full-time
Yeah, do that if you think that it a good idea. For example, write an application which is using a mariadb database. Then someone comes and says, we need to also support Postgresql and Oracle because our customers want it.
Now, either you use some pre-existing database abstraction layer, or you will have to write it yourself. And the 2nd option is often not the correct one as you will suddenly have a big effort. Just to show one example where this thinking falls apart.
Usage of too many libraries can be also bad but not using them at all is not possible unless you are a hobby coder.
Fine. But are you really going to write your own HTTP server in C? Good luck with that.
seminar called "why isn't functional programming the norm?" is basically all about the history of OO programming. And yeah, the original conception isn't obviously bad or anything.
Regardless of whether or not you think its good, you have to acknowledge that it did not become ubiquitous BECAUSE of an analysis of the usefulness of the doctrine. It became ubiquitous because of fashion. C++ became the fashion, java was marketted to C++ users and new programmers, and javascript was marketted to java users, and so-on.
Yes, it was all about mindlessly following fashion.
Thanks for your content
Having spent nearly 15 years writing code, I've found that most people are using classes more like modules organising functions (particularly in Java). From my experience, files & folders are the best module system for organising code and classes are most useful when reserved for validation whether that be validating a collection of values (as an object - like contact form details) or a single value (like a 255 character string, an email address, a positive number, etc).
When it comes to inverting control, I don't until it's necessary, and when it becomes necessary, I opt for more of an adapter pattern with functions, where an adapter function sits between my implementation functions switching between implementations based on an environment variable or an additional function parameter. This makes it really easy to navigate through the actual implementation code and reduces abstractions. The obvious issue with this approach is that I could easily forget to provide an adapter and implementation for a particular function (e.g. a database call to create a record) whilst having adapters and implementations for all of my other database calls. I suppose it's an issue I'm willing to live with for the benefits the approach provides, if it were a serious recurring issue, then I could make use of some facade-type pattern.
Ig the general thing to do is start small, refactor as you go. Its even logical as you cannot see the whole picture to select a proper design pattern when you start your project.
Lot of good stuff here. Although I do know that I could never have grown my modeling app from 10,000 LOC to 400,000 without C++ and OOP, it solved some wicked problems and kept the codebase maintainable. Of course if you misuse C++ and misunderstand OOP, you'll have problems (and I did too, early on).
Is that app open source
@@skyhappy No.
> Of course if you misuse C++ and misunderstand OOP, you'll have problems
So, you understood OOP? Can you explain it to us?
@@etodemerzel2627 OOP is essentially data- or type-centric. Alan Kay's perspective was to favor messaging between objects and binding as late as possible (encapsulation and control inversion or dependency injection). C++ offers compile-time binding via its inheritance model (for performance reasons) but not surprisingly, it gets overused and causes dependency problems. Smalltalk's philosophy of "building a network of virtual computers to divide and conquer the problem domain" seemed to get forgotten or misunderstood.
@@perfectionbox Cool... I guess? That didn't explain anything to me.
There should be a need for OOP in what you are doing. If you need it, you'll naturally gravitate towards it
“Where is the actual code” a great way to put it
nothing is bad, OOP is not bad, FP is not bad, AOP is not bad
everything is a tool and people just learn to use the right tool for the right problem.
If you understand basic thing about code readability and maintainability everything else trickles down from it : key to readable/maintainable (good) code is make it so completely unfamiliar developer (or maybe you in 3 weeks) looks at it and spends least amount of time to exhaustively understand what it does and how to modify it. Having 7 layers of abstraction and being forced to debug to understand which implementation actually executes code is bad, having 7 levels of higher order functions in FP which creates a function that creates a function that creates a function that does stuff is bad... its not about less lines of code either, one can write crypting hard to understand one liner using all sorts of language features but the same thing will be significantly easier and faster to understand (and debug) when its a couple of if statements with good naming of everything.
Its not hard : good code = least amount of time you need to spend on average to understand any portion.
Most of the principles of OOP were developed under the environment of hundreds of developers were working on monolithic desktop GUI apps.
Most people don't work on these sorts of things anymore but still adhere to these principles. It's my opinion that if you're working on a codebase that only a single small team touches, SOLID code is damn near an anti-pattern. You have luxuries that people that developed SOLID never had.
this. objects make a lot of sense in UI because they mostly represent widgets which are little islands of state and behaviour with hierarchies which can also call each other.
not so much in other domains. these days modules, closures and immutable records are all the rage
There are literally billions of solutions to programming problems. It's about choosing the right one for your particular case.
Not everything needs an interface or base class.
Not everything needs to be injected through DI.
Not everything needs its own library.
Not everything needs clean architecture or DDD.
Follow these and you’ll be fine.
You also should know that abstraction may hit performance in applications like computer games. So, it means that game developers have to account for performance each time when common mainstream principles like SOLID are going to be used, and often there is no actual benefit of using them. As games are performance-demanding systems, there is no way to ignore the cost of using abstractions. On the other hand, web developers, especially front-end guys, don't even know what does word "performance" mean. That's why we have such rebelliously inflated overcomplicated systems today.
OOP isn’t the problem imo. The problem is bad design, sometimes in the form of over-engineering. I’ve also noticed a lot of times it’s a failure to correctly model the right things in your apps domain. This makes reading the code - and therefore changing it - tedious. Maybe the problem is OOP is too hard to get right, and I may agree with that.
And the poor object hierarchy is ALWAYS something that happens when you work with far more abstract or technical problems. OOP only works for business projects because business processes are basically all object and everybody sees that an Invoice is an object and that an invoice is send to a Customer and a customer is a Person. It gets so much harder already with embedded systems are interrupts objects? Are ports with 8 pins each objects? One would say yeah a port is an object with the x amount of pins. Others would say no a pin is an object and a Port is collection of pins and that can be an object but can also just be a vector because you can bundle other pins than too. The thing is, they are both right and it gets obfuscated by presumptuous object hierarchies.
So in 30 years of OOP I have literally never saw an object model in anything bigger than a single function program that made sense and was easy to understand -- even when staring at the UML.
I have seen assembly code written 40 years ago, that I can deduce instantly what it does just by clear functions and a nice block of reserved memory for variables.
Look at this from a different perspective. Instead of thinking about it from the perspective of the programmer let's look at this from the perspective of the end user or the perspective of the business. Does applying OOP to everything improve the performance of the code? Does applying OOP to everything reduce the amount of bugs? Does applying OOP to everything reduce the development costs or development times? I would argue the answer to those questions is "The majority of the time, no".
I got my first job after college is because I could program in assembly language. Not quite "bare metal", but close.
i dislike OOP, but it might solve problems other than what a program has to do. For example it might enable organizations with silo'ed non-crossfunctionional teams to to do their job. The teams encapsulate their part of the code and make only very small parts public and other teams only can use it the way that the original team designed the class. Not sure it's the best way to solve organization culture issues, but sometimes it is what it is.
Surely the point about writing any program, is that you need to model the problem to understand it. Then you need to choose a language and model a solution navigating the strenghs and weaknesses of the chosen language.
The idea behind object oriented programming is to build useful objects that model aspects of the solution. Frequently (though not always), this leads to a more maintainable solution, because the objects modelled in the problem mimic aspects of the solution.
Like any tool, object oriented programming can be abused. SmallTalk is nothing like C++, but you can write object oriented solutions to something like the Game of Life in both languages that have a lot of structural similarities. Smalltalk is more "fun" and is faster to write, but C++ is less likely to suffer scalability and portability issues in a production environment.
Programming is a hard skill to master.
...and remember: a good Fortran programmer can write Fortran in any language 🙂
Honestly at this point I mostly write at most, if any inheritance at all, one layer.
Most of my code now doesn't use any inheritance. If anything I might make a Component interface for a game engine, and have that be the only actual inheritance.
My code has gotten so much better by somewhat (but not fully) abandoning OOP fundamentals. I use objects, and I use encapsulation, but not much more than that.
Also not fully related, but overuse of DRY and SOLID can make your codebase a pain. Don't be afraid to repeat a few lines of code, and for SOLID, specifically the SRP, don't be too dogmatic about what "one thing" is.
Also many people think of srp in a wrong way according to the author single responsibility usually refer to an actual real world actor it may be a person or even a business department
If you use IoC container , you will need to deal with bugs in the IoC mechanism . That can be a headache .
While OOP is a means to an end and has many useful principles, primarily around managing complexity as codebases and teams grow, it’s ultimately a religious practice that introduces more barriers and confusion than it purportedly solves. This is my gripe with typescript - I see all these barriers and complexity being reintroduced into JavaScript, which became favorable due to its extreme flexibility. You can have types AND keep a simple modular, functional architectural style to keep it simple.
So to summarize, OOP is more boilerplate, so don't use it prematurely.
OOP is more boilerplate, so don't use it at all. Programmers claim to want simplicity but then add 15 layers of complexity.
@@CyrilCommando sure lets make a back end API purely procedural 🤣
I guess you people prefer your application code in a single python file
@@Fantaztig lol you can make your code modular while not abusing oop, they're not mutually exclusive.
Perfect
OOP is a tool.
Like any tool, if you use it wrong, it's gonna suck.
Stop blaming the tool and start improving as an engineer.
I think it just doesn't make sense when you got a problem to solve and the first thing you think of is "how can i first of all conform to this OOP design standard before solving the actual problem. I think the right idea is to first think of a solution to the problem at hand, then implement the most simple/understandable solution and, if the probability of having to make that piece of code open to future changes (like when its a domain knowledge that changes/grows often) is low, you can just leave it at that. You can even tolerate duplication instead of DRYing out the code right away if that's the case, for instance.
The thing is when you know the code will have to grow to conform to the increasing domain requirements, and you see you're just adding more ifs and elses, you naturally think "there's gotta be a better way of doing this". And usually this way involves going up on levels of abstractions and unavoidably creating some level of indirection. It's all about tradeoffs. So instead of thinking of a preexisting design pattern to conform to, whe should flip the situation on it's head and start thinking from more concrete to more abstract -AS PER NEEDED. So we should first try to understand why/how these design patterns first came to be, like what's the problems they were trying to solve when these things came into existence? Why do they exist? And go from there. It's far more productive to follow design guidelines, like making some good design questions as you code, then just implementing some OOP philosophy if it matches your situation, and iterate from there than just thinking first of an OOP design pattern and try to make your domain fit into that structure. Of course i don't believe OOP is perfect, nor that it solves everything. It's just one more tool, and nobody should be faithful to only one tool :)
6:18 most professors have not worked in the real world
The way OOP is taught is fraught will bad ideas and half implementation and poorly cobbled concepts that work under certain circumstances and not at all in others
It’s interesting to study the origins of these things, it was all based on hype cycles from previous ages
Thinking of a function as solving a specific problem within a limited domain is a great idea. Objects just aren't a great approach to this idea. And OOP paradigms like inheritance and polymorphism just exacerbate the problem further. Hiding a function within a translation unit, and thinking of a translation unit as being a domain is a pretty intuitive and useful way for encapsulation but not the cleanest way for sure. Still better than objects though imho.
There is a bit of an issue with critiquing OOP (which certainly has issues)in this way: every programming paradigm does not generate code, they are all abstractions. Indeed, compilers are abstractions, they don’t write code and they only facilitate the abstraction of high level programming languages… so there must be a more accurate critique than “OOP doesn’t write code”, for example the amount of boiler plate overhead OOP requires
Btw, I use objects all the time in programming, but I don’t think I have ever conformed to strictly OOP standards
It’s the architect who do this to show there superiority. Some do it in purpose so the code remains visible to them only and this secures there jobs for a longer time. It’s easy to spot them just ask them to give technical documentation with activity diagram for each classes instead of functionality and they will make all kind of excuses
There are always solutions in software. Angular and Nestjs allow you to structure your code into independent modules that hold components.
Wait... did you just pretend that C does not allow you to do the exact same thing... and has for over 50 years now? ;-)
Yep. I've been saying this for years now: abstraction has to be justified by its payoffs. And not everything needs to be abstracted according to the "ideal" OO paradigm. Doing that only brings you closer to being an Architecture Astronaut - not a good thing.
OOP is like the most elaborate California Closet's design you could possible install in your closet. When all you needed were a couple of wire shelves.
Generalizations first are the holy grail if the abstractions are good. The problem of that people suck at writing good abstractions.
Premature optimization is true. Thus I don’t mind to refactoring it later. While your boss would fire you before your refactoring, and you leave a bit mess to the next one
I had Smalltalk-80 way back when, around 1980.
Build layers of abstraction,
not layers of distraction.
They killed goto to prevent spaghetti code they killed procedural to prevent random access global they killed OO to prevent indirection etc..
It seems many past software concepts have been abstracted away over the years and maybe the technology will change full circle someday and we can go back to just solving problems without all the extra seemingly unnecessary complexity. i.e. The cloud concept is hardly a new concept. The mainframe computer paved the way conceptually for cloud computing. Back in the day (and even today's mainframes), several companies share/shared (and are/were billed separately for) execution time, space (DASD and tapes), dev teams that write/wrote applications, etc. It seems, in general cloud computing applications today are over engineered/abstracted and eventually will cost much more than the "on prem" systems/applications they migrated from. Amazon just needs to nudge the price of its plethora of cloud services/abstractions higher and higher each year. This will force companies to re-look at "on prem" in the future. And/Or companies with stick with or go back to using mainframes. It's just a matter of time.
Python is object oriented..we talking about objects and methods ...every piece of of data ,functions, and types are objects...earlier languages were procedural with unconnected data types and operations..in python all data and operations can be attained using a particular objects' methods..
Ie strings are objects
Everything needs to be abstracted so we can mock our code and test it my friend. You keep asking questions yourself that have super obvious answers. Having said this, I prefer to create interfaces for functions than classes. I think its a lot cleaner when we do this. My main concern with OO are the mamushka dolls of multiple layer inheritances that end up creating confusion. Typeclasses is the way to go
I have been tip-toeing around the "devs are too dumb to make code that works" argument for so long, so thank you for saying it. I haven't worked in industry as a developer, so I have hesitated to pass judgement on all these various ideas like OOP vs fuctional, micro-services vs monolithic, etc., and I have heard all the arguments for these "belief structures" that people have. And I have always wondered what problem are people trying to solve? How are they trying to solve that problem? And it seems like to me that the decision to choose OOP vs FP, micro-service vs monolithic, etc. is never as an answer to either of those questions, it's always an answer to a completely different question that has nothing to do with the problem at hand. Again, no industry dev experience, but it seems to me that the decisions being made on thing like OOP vs FP are about continuity of operations and other business decisions, and have very little to do with actually solving the problem at hand. Exactly like you said, it's about ensuring that the development process at a business can be easily migrated from developer-to-developer, from team-to-team. Now, yes, the current state of industry-style development does seem to necessitate things like OOP and micro-services, despite the fact that so many incredibly talented develops seem to not like them as go-to methods. That doesn't mean that any of these things are concepts you should never use, but it's like what Blow is saying--it should be done as an intentional choice when it becomes apparent it is useful, but not taken as some programming dogma. Because then your choice is about solving a problem programmatically.
There's no need to pass judgement. They are tools. Ever hear a carpenter say you should avoid using a hammer (OOP) at all cost. A hammer (OOP) is objectively bad.
Any professional carpenter will laugh at that statement. Yet for some reason this flies in programming world.
I'm really not trying to be argumentative, but yes, I have actually heard carpenters (and all sorts of other tradesmen) make arguments about what is Objectively The Best™ way to do something, once you take a step into their expertiese. For instance, I have heard carpenters say you should never, under any circumstance, cut a 45º angle unless you used the angle measurement built into a tool to do it. Even if you use a square and geometry to ensure its absolutely a 45º cut, there are guys who will swear that if you're not using the compass built into your miter/table/circular saw to measure the angle then you're going to be off. Ask a random assortment of plumbers about sharkbite connections, and you will definitely find some insisting they are objectively, undeniably unuseable. Many electricians will swear that you should never use an arc fault breaker except to pass an inspection. Don't even get me started on the arguments about which tools brands are objectively better than others. So, no, this thing does not solely exist in the world of programming. It exists whereever there are people.
What I think you're missing is - you gotta pick something. Procedural, FP, OOP, whatever.
In general, for a given project, there might be an obvious choice (C# for Unity) or obvious bad choices (C for webapps). Outside of that, picking the "right" thing is most likely about picking what you're most familiar with. I can guarantee you almost no one is going out there and taking a survey of all potential programming models and technologies before they pick something for their project. That includes Blow.
@@bobbycrosby9765 I don't think anyone is arguing against the reality that choices need to be made and that those choices can be daunting. What Blow is literally saying is that sometimes choices being made have less (or nothing) to do with that choice being a good way to solve a problem, and more to do with the fact that people have arbitrarily taken the choice as some kind of standard to always use. There's a big difference between looking at the choices you have most readily available versus trying to look at the entire world of programming for potential choices, and there's an even bigger difference between actually evaluating what's immediately at-hand versus just arbitrarily deciding.
The thing that is being criticized is that the reason something is being chosen is often because the thinking is precisely "we just gotta pick something", and it doesn't get investigated further than that, sometimes even if there's tons of problems.
I so agree with your point. Entered the Java world recently and I'm really overwhelmed by the overuse of object oriented patterns everywhere.
Well, I think the problem with object orientation is heavily related to the "code-is-your-friend"-faction which mindlessly produces masses of code only for the sake of having said to have reached a new maximum of lines of code per day.
And management enforces that, more code = more productivity.
Until the senior comes up and has to cry about the bullshit the other people have done again...
"Any problem in computer science can be solved with another layer of indirection, except of course for the problem of too many indirections." --David J. Wheeler
Go ahead and add an extensibility point if you are going to actively use it. Go ahead and carve out interfaces if you are going to use them in a meaningful way. But be wary of adding layers upon layers for the sake of having layers or "we'll need it later" because you will be increasing complexity without adding value. And adding that complexity will come at the cost of increased difficulty in understanding and maintaining the codebase. In other words, make sure the juice is worth the squeeze.
Inventor of OOP Alan Kay many times talked that they absolutely butchered his OOP. They just take the name but implemented something that was almost 100% different than what he meant. His OOP is like actor model of Elixir/Erlang .. objects sending asynchronous messages is THE idea of his OOP (async messages is bigger idea than objectes there). But in modern oop objects are connected and using synchonous method calls and its just a very different thing 😢
Details do matter. Expressing something in black and white tones is oversimplification.
I agree, that OO is overused, but its not "bad". The bad thing is that, when you have only a hammer, each problem looks like a nail.
I would appreciate to see thoughts about where its better to use FP over OOP and vice versa.
Thanks
The problem with OOP is poor type systems and bundling over 20 features into one concept of OOP
I really appreciate the comments of the collective experiences of engineers. However the videos touches on valid points, it would be nice to provide details of alternative approaches. I see a lot of agreement with the videos sentiment but few discussing why, that is, better alternatives.
Kinda feel the same way. Too many times, we have projects that have so many layers of abstractions (factories, interfaces, abstract classes) for the sake of abstraction. The code becomes immensely difficult to follow and drains all your energy trying to understand what's it's actually doing.
Also, remember the good old days of TheServerSide design patterns overload? Ppl came up with patterns just for the sake of coming up with patterns. LOLs...
Oh, we are having "makeStategy" utility at our project. And the author can't get it why it's bad idea. So, I just rewrite it to switch-case statement :) For my 15+ experience I found clear concept - "Write code for peoples, computer is smart enough to make it work, so focus on readability only".
My rules.
Never use inheritance always composition.
Use interfaces.
If for some super special reason where it actually makes sense inheritance max one level.
Start with one file, PODs and free functions only.
When a function and data really ties together create small objects with one or at least very limited responsibilities and more files.
Start with everything public make private when access really needs to be limited.
No getter/setters.
Never use protected, imo the worst source of spaghetti oop never knowing at what level state is changed.
Same rules for templates, only create them when needed, some(a lot) start making template libraries like they are writing new stl functionality while they only have one type.
Same goes for exceptions/error handling/logging other than debug purposes, implement first when it is clear how things turn out and what can go wrong and where, some (a lot) create custom exceptions, complex try/catch hierarchies and logging when all they have is one type cast.
Never future prof anything if you don't know you will absolutely need it.
Re-writing simpler code even from scratch when conditions change is faster than adapting over engineered oop spaghetti.
It is like people are afraid to just delete code that does not solve a problem anymore, building one superstructure to rule them all, only adding to it never taking something out.
Tldr. Start simple and keep it simple if you can, patterns are for cs students 😀
I hate when ppl create a transitional/mediator class for the sake of abstracting one aspect of an entity, increasing the layers of functionality. In theory it makes sense in the sense of separation of concerns and you try to future proof but I think it just makes things confusing.
In my opinion this is something that Go does very well. It's actually very difficult to over engineer and over complicate go code. You can also make beautiful code in Go. It doesn't force you to adhere to any principle. You can do functional in some places, object oriented in other places, procedural in some areas
How can anybody disagree with this video? I'll give it a shot.
First: you don't create the abstractions first and then try to somehow squeeze code into that set-in-stone object structure. This is a ridiculous straw man argument to take down OOP.
It's the other way around. You solve problems while coding and start noticing patterns and almost-but-not-quite the same things appearing. Then you create abstractions to make sure you code every needed piece of functionality exactly once. You use the SOLID principles to guide you: Liskov substitution tells you when inheritance is a good idea (less often than you'd think), Single responsibility tells you what functionality should be extracted into its own class, with it's specific responsibility, and so on.
Second: you program to interfaces exactly because you need to '"add a different dependency to this class [after a set period but 10 years is ridiculous]".
With proper OOP, everything has its proper place and responsibility and if you add something, you already know if it already exists in some form or you need something new. Something that exists can be modified without affecting anything else because of the dependency inversion and other classes just depend on the interface. Something new is just added there and then and the new interface is added as a dependency without a hassle.
If you don't need abstraction, you don't add it. But if you're going to have code duplication and responsibility creep all over your code base, don't come complaining if you change some functionality and end up discovering your change isn't implemented properly everywhere and your maintenance time is out of control.
Honestly there is no cure fore skill issues and corporate politics (Conway's law) -- regardless of OOP, FP or "memory stitching and hole punching" Programming.
Even though I am not in this industry for more than 15 years, I can observe that there are more sheep than wolves when it comes to critical thinking. Be it Scrum - Agile or waterfall, FP or OOP, JS or Java, CloudFunction or Docker, TDD/BDD/DDD...