Project anecdote coming up. I worked on one project, late 90s, about 30 developers, the management had things so buttoned down that the open-plan office was as quiet as a library. I suppose they thought that better progress could be made if everyone was seen to have their nose to the grindstone. Anyway, I was just leaving one evening and I got talking shop with a colleague on another team, and suddenly we realised that our respective subsystems weren't going to work correctly with each other. So I went to admonish the project lead about why no-one talked, he stared at me like an owl caught in headlights, "say what". Nothing changed. Teams need a culture of collaboration and communication, can't be done through specifications. Projects that really worked, there was always a quiet but insistent hum, I always listen for it as a first impression of the health of a project.
@NitsanAvniКүн бұрын
Love the thumbnail!!
@asteriondaedalus68592 күн бұрын
The problem with oo designs is the obfuscation of the functions. Which is why functional programming is making a comeback. Viva Elixir!
@NomadicBrian3 күн бұрын
I initiated with FORTRAN and ASSEMBLER and COBOL. I instantiated with C#.NET, Java and other object oriented languages because that is what the client asked for and they paid me money for it. Soon my finalization will come as I complete the loop of life. For now OO ...there it is.
@nickbarton31913 күн бұрын
I was always fascinated that God gave Adam the responsibility of naming the animals. Just shows how important lexicography is.
@user-mu6ii3jg1o4 күн бұрын
The most vital things NO ONE talks about. They keep hashing the same daft examples involving shapes or animals.
@explorster6 күн бұрын
You are always complaining about everything.
@ThePassionateProgrammer4 күн бұрын
Always? Everything?
@NineInchTyrone6 күн бұрын
Modula3 ?
@spayeur6 күн бұрын
Please consider this constructive criticism and not bitching. I've watched three of your videos and, so far, most are hand-waving and don't really instruct or inform. It is easy and pleasurable to talk in platitudes, but actually moving people's processes forward requires more meat. This video is entitled "How to Create ELEGANT SOFTWARE DESIGNS", but how much of the content actually taught that? Love your idea, waiting for the delivery.
@NoahNobody6 күн бұрын
Yep, I for one would like to see an example of this thought process.
@NoahNobody6 күн бұрын
I tried to write a php unit test today that checked the return value of a method. Inside the method needed to fetch a bunch of objects and get one property from them with a getter. So I mocked the getter giving the value and the value inside the object ended up being null. I had no idea why and I was on a tight deadline and didn't have time to start debugging how the library was not doing it, so I commented out the test and left a comment saying what the test was supposed to do and whoever was welcome to fix it.
@swedishpsychopath87956 күн бұрын
uh oh, you just killed Kotlin
@christopherscottdempwolf57596 күн бұрын
I came to programming from a background in architecture and planning, so I was familiar with Chris Alexander's "A Pattern Language" trilogy before reading Design Patterns. I suspect you've read them too.
@NoahNobody7 күн бұрын
Where have you been all my life!
@ThePassionateProgrammer7 күн бұрын
I’ve been training software developers at the top companies around the world for the last quarter of a century. But now I’m sharing it all here on this channel.
@NoahNobody7 күн бұрын
We are lucky to have you ♥
@pedrohenriquenepomuceno38777 күн бұрын
Thank you for your passion and for sharing valuable information
@ThePassionateProgrammer7 күн бұрын
You are welcome!
@tyranmcgrath68717 күн бұрын
What's the difference between extension and modification?
@ThePassionateProgrammer7 күн бұрын
Open for extension means that you can add a new behavior with minimal changes to existing code, ideally just in the factories. Closed for modification means that in order to add a new behavior you have to make many changes to existing code. We prefer to have our designs be open for extension when possible.
@SimGunther7 күн бұрын
His code is so closed source in every video it suddenly became "open" thanks to the open-closed principle 😂
@nickbarton31918 күн бұрын
Yes, I like your compromise, I've never added features to an existing system where I didn't have to do at least some refactoring. But I like your idea of reviewing looking for weaknesses which would prevent OC principle.
@ThePassionateProgrammer7 күн бұрын
Thank you.
@vlahunter8 күн бұрын
Your videos and your channel is an oasis in a desert of madness. Sadly we developers spend time learning tools and architectures that never solve the real issues. Simplicity is key here and i see that the past years whenever i solve a problem well, i do it using simple and well tested principles, followed by good tests and generally make it easy enough to be extended with new requirements all else are white noise. Keep it up, the value your videos provide is huge!
@ThePassionateProgrammer8 күн бұрын
Thank you. You made my day!
@JonathanPlasse8 күн бұрын
Please continue doing both
@Nellak20119 күн бұрын
When I hear OOP devs talk about encapsulation and inheritance, it is mentally translated to: "Make your program hard to test" and "Make your program tightly coupled by over engineering" Then they say this is good design.😂 😂
@carjaune679310 күн бұрын
Nice desk
@ThePassionateProgrammer10 күн бұрын
Thanks.
@clumsyjester45910 күн бұрын
I don't have enough experience as a developer, but I think OOP is mostly suitable for use cases where parallelization is hard anyways and where abstractions themselves are actually valuable. The best case I know of is web development. Every request is unique and isolated and you can't really parallelize them. And if done right, most classes and objects conform to some business rule, legal entity or process. But I would try to use as little OOP as possible in other fields.
@heyyrudyy40410 күн бұрын
The point in this video is about Offensive Design & Offensive Programming in opposition to Defensive Design & Defensive Programming which lack intention, thus responsibility, hence making your code garbage.
@soberhippie10 күн бұрын
This all sounds scary, like a cult welcome speech or a programme from the Matrix talking
@Cdaprod12 күн бұрын
Thanks so much love the passion. I’ll be sharing this
@ThePassionateProgrammer12 күн бұрын
You are so welcome. Thank you for sharing!
@TomBaldwin-n2u12 күн бұрын
Another good video As an aside, it was OOP which informed Alistair Cockburn's 1990 "Crystal" methodologies Teams have their own data. They have their own processes. They look after themselves. They have Events. They have the public & private. Abstractions The parallels are there Most organisations are like spaghetti code, GOTO statements & Global variables! 😉
@aboringfart41312 күн бұрын
OO programmers don't add 1 and 2. They create abstract numberFactory classes and instantiate a numberOneSingleton object and a numberTwoSingleton object. Then they create an interface class for abstract classes including an add method. Or was it an abstract class for interface classes?
@davidboreham13 күн бұрын
This would carry more weight if there were code examples.
@theMuritz13 күн бұрын
You deserve my sub fellow white beard … it’s refreshing to have a mature face talking calmly and competently
@jimiscott14 күн бұрын
IMO your point around DI is wrong. In large systems DI is almost a requirement as you end up having to implement a DI solution.
@davidboreham13 күн бұрын
DI is just a fancy obfuscating name for global variables.
@jimiscott12 күн бұрын
@@davidboreham No its not and you don't know what you're talking about.
@adambickford87205 күн бұрын
@@davidboreham Completely clueless.
@nickbarton319115 күн бұрын
David, can you please expand on ways to measure improvements.
@ThePassionateProgrammer15 күн бұрын
Yes, I made a whole video on that. kzbin.info/www/bejne/l5W0l6B3hMyEocksi=QgYCIDkZWBeAB-pq What do you think?
@nickbarton319114 күн бұрын
@@ThePassionateProgrammer Just watched it, yes thought it provoking. I do dislike the term "sprint", gives management completely the wrong idea. In fact, I think the concept should be abandoned, just take the next "low hanging fruit" use case from the backlog and work on that to completion. If it's too big, break it up. Usually, backlogs become far too big, more like to-do lists or memory aids and as such a distraction. By and large, our efforts to formalise software engineering processes have failed, we should have concentrated on good practises and measured outcomes.
@MatrixQ15 күн бұрын
I was the same when I found that design pattern book. So eye opening.
@amira-supermiemie16 күн бұрын
Good observation. I think the original ideas of Object orientation has been lost throughout the years. People are locked in in those so called best practices without understanding the root and essence of the object orientation. It’s not OOP it has way more applications than just programming. Engineers should learn how to think not just follow paradigms and methodologies.
@ThePassionateProgrammer15 күн бұрын
I totally agree. I think you are going to love my videos! Welcome.
@perseus08616 күн бұрын
Cool robot lamp
@ThePassionateProgrammer15 күн бұрын
Thank you!
@vladislavaleshaev766216 күн бұрын
Completely agree! For less experienced developers as me, where would you suggest starting to learn this approach-focusing on abstraction and designing software from that foundation? Specifically, are there any resources, such as books, courses, or examples, that you would recommend to help understand how to effectively organize business logic, processes, and maintain a clear division of concerns? It would be great to know if you offer a course or could point to some valuable examples on this topic.
@ThePassionateProgrammer15 күн бұрын
Actually, I do offer a course coming up later this year. More info here - tobeagile.com/training/ and you’ll also find lots of resources on my website. Enjoy and I hope to see you in class!
@user-mu6ii3jg1o15 күн бұрын
In principal. Abstractions usually take a form of evolution so the effective realization of abstraction tends to come into being often later rather than sooner. Between now and then you have to put in the work to grind through the logic.
@atabac16 күн бұрын
object orientation approach was basically for management people and neophyte developers who are not really into technical stuff. it does not work for super developer who works alone and can finish large, complex, software by himself.
@RealisableSoftware14 күн бұрын
Wrong
@gruntaxeman374014 күн бұрын
Wrong. In management, software architecture actually very much also people management, what team handle what stuff, and those teams or developers communication channels are equal to software architecture. OOP is unrelated to that, also super developer that can create software alone (like I do) is not the point. I wrote those initial software versions and other people can jump on those, and it very important make understandable structure. We have software frameworks for purpose. Without software framework, I should document all details and conventions myself. With ready framework, those can be found from framework documentation.
@atabac13 күн бұрын
@@gruntaxeman3740 wrong. software architecture and people management are two different things. frameworks doesnt care about how it is coded(like how strict OOP you used or some other code style shit), all of it are abstracted, all it matters is performance. extensibility can be solved by releasing new version. usability can be improved in next versions. you dont actually need to write documentation for frameworks you've written unless you intend it to be used by neophytes or non-technical because code itself is self-documenting.
@atabac13 күн бұрын
@@RealisableSoftwareyour probably dont code in low level😆
@gruntaxeman374012 күн бұрын
@@atabac Code usually don't tell decisions what is lead to current design and it has mappings to surrounding world, and information of surrounding world isn't necessarily in code. Also it is very well known fact, that software architecture is same as team structure or communication channels between developers. This was observed back in 60's and it is true today. That is why we have for example microservices, because there are different teams working on different services independently. Also because humans do have limitations, it forces to make architecture decision because one dude can't efficiently work on 1M lines of code that is just one big chunk of dependencies that need to understand as whole. Even the super developer requires there architecture that he can work on module or component level without caring rest of the code base.
@williambyrne685516 күн бұрын
Began with K&R's C in the early 80s and embraced Bjarne Stroustrup's C++ not long thereafter. But decades later, the Design Patterns dictate was the absent-minded middle-management directive that gave credence to the same middle-management that knew none the better. However, today's non-poly object modeling is perfectly okay. The wide support for interface abstractions serves the vast majority of requirements. And I'll wager that AI language infrastructure is non-polymorphic.
@fredrikbergquist573417 күн бұрын
My experience is that the UX developers have too much influence in the design of the project. The business model isn’t defined first. The boss says that the buyer of the commercial product only sees the UI so that is the most important.
@nickbarton319117 күн бұрын
Smart constructors, I've only recently discovered them.
@nickbarton319117 күн бұрын
Love your enthusiasm. Definitely don't start with the UI, it leads to a ball of mud of cross coupling. There's another downside, managers think that you've finished if they see a UI.
@ThePassionateProgrammer17 күн бұрын
@@nickbarton3191 Wow, that happened to you too? Back in the day circa 1989 I built the dialogs for a program in OS/2 in two days, just the dialogs, but my manager thought I build the whole program. It was hard to convince her that there wasn’t any logic behind the buttons. Now I start with the business rules in testable objects and later I build the UI and I don’t put logic in the controls. I find I end up with a much better separation of concerns.
@nickbarton319117 күн бұрын
@@ThePassionateProgrammer Happened to me more recently, like 10 years ago, I built the front end AngularJS, HTML, CSS, lots of animation but dummy data. My guy wanted to start populating the database, lovely, well-meaning chap who did understand my explanation even though I'd already presented a project plan. DTOs are the best solution to UI separation, leaving the UI to deal only with presentation issues.
@jimmiller933017 күн бұрын
OOP- Obfuscation oriented programming. When no one else can understand your code. The key to job security.
@user-mu6ii3jg1o15 күн бұрын
But why obfuscation? OO is really a principle of encapsulation which can/is a good thing. OO is really nothing more.
@makiroll996011 күн бұрын
@@user-mu6ii3jg1o how about instead just having Module (Data)structs Functions ?
@zulupox3 күн бұрын
@@user-mu6ii3jg1o Excessive use of abstraction. Too many layers of abstraction. It gets way harder to reason about than straight procedural code.Also code gets bloated. Way larger.
@user-mu6ii3jg1o3 күн бұрын
@@zulupox Not necessarily. You have complete control over the level of abstraction. You are not compelled to do OOP. Still it's not perfect. But procedural code also tends to become spaghetti code quite easily. Coding doesn't appear to be taught properly.
@zulupox3 күн бұрын
@@user-mu6ii3jg1o True. You can pick and choose what parts and how much you want to go with OOP. Problem is that people loves to build these over complicated towers of abstraction. 10x harder to understand what the hell is going on than not using it. Imho it is a myth that is being retold that procedural code becomes spaghetti more easily. Perhaps dating back to the 80's when everybody getting home computers dabbling by themselves in basic and goto's as beginners. Not really an issue for a professional programmer.
@cbbcbb680317 күн бұрын
People created computer programs before OOP was created. How, then, did anything get done?
@ThePassionateProgrammer17 күн бұрын
@@cbbcbb6803 I think OOP helps us write more scalable systems that are much more complex than what we could build in procedural code back 20 years ago. Sometimes it is hard to see progress but if you remember what software was like 30 years ago like I can the difference is stark!
@user-mu6ii3jg1o15 күн бұрын
Asking the wrong question. The quality of engineering in software is generally poor regardless of whether it is OO or not.
@jamesstelvin17 күн бұрын
Dope
@PulpFreePress18 күн бұрын
I love browsing software design books too!
@dreastonbikrain189618 күн бұрын
This video as all the other OOP: books, videos, and uncles - sounds chaotic vague an unscientific. No proof, no explanation, only opinions and "trust me"-s.
@adambickford87205 күн бұрын
Funny, that's EXACTLY how OOP was sold. It took decades to admin the emperor is naked.
@derekreed679818 күн бұрын
I have come across this saying alot; 'Do it right first time'. The premise with this is 'to be perfect'. This premise totally goes against agile's 'good enough' and incrementally improvement (and life). To take on the philosophy 'do it right first time' stifles any creative process by making you fearful of getting things wrong.
@ThePassionateProgrammer18 күн бұрын
Yes, exactly. Perfection is expensive! All the best devs strive for good enough because that’s the most cost-effective approach. Well said!
@derekreed679818 күн бұрын
Funny I came across this (well maybe not it just shows the algorithm is working). I have been asked to look over our OOP code with the remit of making it more flexible based on interfaces/abstraction. Thanks for your reflections they are very much 'food for thought'
@ThePassionateProgrammer18 күн бұрын
You are welcome!
@khatharrmalkavian330619 күн бұрын
I keep hearing people gripe about OOP and when I ask them what's bothering them they immediately start complaining about the consequences of all the things you're not supposed to be doing in the first place. I suppose the real downside to OOP is lack of education. It's too easy to pick up a language and start using all the features willy-nilly, but until you learn the basic design principles you're always going to have a mess on your hands.
@ThePassionateProgrammer19 күн бұрын
I totally agree!
@cbbcbb680317 күн бұрын
But, people are willy-nilly. They are not oo programs.
@johnridout654017 күн бұрын
I think OOP is fabulous for user interfaces and many other purposes, but with multi-threaded services I avoid mutable state as much as possible, which makes OOP a bad fit. I still use objects, but I don't approach it from an object oriented perspective. It's not the only tool we have and sometimes it's the wrong tool.
@sealsharp14 күн бұрын
The teaching is stuck in mid 90ies "model the problem" attempts. How are you supposed to understand when abstraction is useful if you don't get data first? The guy who made OOP was a biology PhD who noticed that bodies are build from immensely complicated smaller cells which are treated by their behavior which was really simple compared to their internal complexity. So OOP principles gave us abstractions like a database-connection that allows to read from a db in 3 lines without needing to write or understand the 500.000 lines that are behind the abstraction. And somehow we ended up with IUserDataCreationFactoryProviderSetupSettingsBuilder. Stop that. Do actual work.
@adambickford87205 күн бұрын
If nobody uses the tool correctly, its a bad tool
@marna_li19 күн бұрын
Another passionate developer here! This is the first time I watching your videos. I'm someone who likes to reason stuff, twist and turn things to finds out how to best understand them. I think OOP, as a modeling tool, is great if you know how to use the language, its structures, to model higher-level concepts through abstraction. I mean thinking abstractly, not using "abstract" classes. I see to many developers who are locked into viewing what they build in terms of the constructs use, rather than the meaning, what it represents. What makes your (one's) approach OOP is not that the language has classes, but that you can model objects and all that comes with it, even dealing with the side effects - using the full range of expressiveness that come from combining multiple paradigms. Hopefully, in an intuitive way.