Problem with S.O.L.I.D is everyone who teaches it uses abstract examples: "Person", "Animal", "Employee", etc. These relations are obvious to anyone, but not all programming relations are as intuitively recognized. I think people should start using examples from real world applications. Show pseudo-code of a theoretical power-point application, sales system, photoshop. Yes, showing OOP is easy when using things we already recognize as physical "objects", but this get much more complex in applications.
Joe Benge Start applying this principle in simple modules, then you'll start to understand on how to apply in complex modules. Please, don't get me wrong, this is a tip and the way I followed.
what is an acronym? it's a brand, it's catchy, it seems to have huge meaning packed into it because each letter is actually a word, woah! SOLID is like someone giving one whole talk on "balance". would you watch a lecture on someone telling you how he is able to stand on one leg for a long period of time? how many lectures do you have to watch before you begin actually practicing balancing? can anyone teach you how to balance in a day? or is it a continual exercise that you get better and better at? are there rules to balancing? sure you have to understand about gravity and maybe intuitively about fulcrum. but you learn by doing it. all of his talks are effectively useless, he's just riding his clean code book. you dont watch bill nye to learn physics, so you shouldnt watch bob martin to learn to code. if you want to watch to learn, you watch someone who actually codes and is in practice. i highly suspect this guy is out of practice. i deplore this bob martin man, specifically because he has so LITTLE to say. but what can you do, right? there are kids and sometimes kids want to watch clowns. and who is going to ban that?
0:00 - Ice breaker - Entropy 6:14 - SRP, Views and SQL, Why separate things? 8:50 - Report generator example 11:41 - Responsibility for one person 13:14 - Mixing HTML and SQL example 14:13 - One change affecting other code 16:17 - Rigidity 17:20 - How can you separate the changes? 17:40 - Employee example 19:37 - Deceptive module; modules should know less about business objects 21:21 - Separate into smaller classes 21:50 - Roman numerals kata, TDD feels slow; comparison using TDD vs. no TDD 26:25 - Separate into smaller classes 30:05 - How many methods should a class have? 30:45 - The database is a detail; should be replaceable; our modules shouldn't care is we use SQL, NOSQL 34:41 - Business rules shouldn't belong on the database 36:10 - Symptoms of bad system design 38:10 - Forced to change in many places 39:25 - Fragility, touch a module and everything works, in a different part 43:00 - Mastermind 45:05 - Responsibilities breakdown 49:00 - Separating is hard 49:20 - Refactoring 50:30 - Separating code should be the last operation
If every programmer (especially the one who called himself software architect) at least watched this lecture or better read his book (better first book on that path) before they started develop complex system how good life might be. Thanks for sharing!
Not all at, it would just raise the bar and then we would have to really up our game to be the top income brackets. Luckily, as long as management focuses on going fast above all else, we won't have to worry about it.
One question related to identifying the people requesting the change. Where does the request for changes for Save() and FindByID() originate from? Sometimes new features introduce database schema changes. Sometimes performance optimization results in schema changes. Would it be correct to mention DBA as the source for change? Origin in the former case is end-user whereas in the latter, it is test team...
Transactions really break the "my application doesn't know it's a (sql) database"... You can definitely isolate very well against the relational model in sql, but I have not found a good way to let an application rely on transactionality of db modifications when the db is not actually transactional...
This. It's about a unique role and about a responsibility towards a user/code group (this agreeing united user/code group should be the one and only reason to change) and not about inner responsibility (cohesion) and Uncle Bob writes about this greatest misunderstanding of the principles in his book "Clean Architecture". Even a simple primitive constant can violate the SRP if it's used by disagreeing user/code groups instead of playing just one role.
Hm, it seems that Mr. Martins understanding of entropy is a bit messed up as he said, that going back in time we should expect the Universe be in a higher entropy state. It is opposite, isnt it? Anyway, great talk.
Because he wants to remember us of the logic of physics and the importance of science. It let the smart persons say what if we add some science as an accelerator for programming? Stupid persons say I just don't get it :)
So, I generally love Uncle Bob (I have purchased all of his books), but this talk was pretty terrible. First quarter wasted to a discussion of physics, after that he is getting somewhere with a concrete example that he is about to show possible solutions for when all of a sudden he cuts off and starts talking about TDD and Katas and then he never gives any resolution to the example. I am a new developer and I would have really benefited if he actually showed some concrete solutions. I can infer what they should be, but what if my intuition is wrong and leads to bad code? I just want to know how he would have refactored the employee class...
+NicholsonLifting there can't really be a concrete example because there are too many. It's not really like an equation, it's more like a philosophy. You have to change the way you think about building systems so no thing is solely dependant on another class, rather you have either an interface or a generic class that facilitates the request. Example: USB is an interface, but can can have many uses. I hope that makes sense!
+NicholsonLifting, I totally agree! I love Uncle Bob, but this is the 5th talk of his that I've watched now, where he opens with an extremely long-winded and unrelated talk about physics! If I wanted to learn about physics, I'd go watch a Neil Degrasse Tyson or Lawrence Krauss talk.
That's the reason classes and systems become harder to maintain and why programming is so hard. Martin gave exactly what needs to understand the basic principle, his intro wasn't out of place, it was perfectly fit into its purpose. And yet you're asking for concrete example or concrete implementation. Use abstract thinking. Or any thinking. Also, intro wasn't about physics. It was about programming industry. It was about computer programs. It was about single responsibility principle.
This is completely and totally false. Requirements changing often means you'll be refactoring often, which means you need very strong unit tests, which means using TDD.
@@adm3333 tests adds at least 30% of efforts to the development. You dont need 100% coverage at start. So cheaper solution would be e2e. That will give some guarantee that main functionality works. And that much much cheaper than tdd. Tdd in most cases is overkill.
@@aleksandrsavvopulo4510 I suspect that you have a different definition of unit test. If your idea of a unit testing includes rampant mocking of internal dependencies and directly testing code in modules other than through entry points, then yeah, those tests suck, but they suck regardless of whether you're a startup or not. Proper module-level TDD unit tests are cheaper than E2E tests and more useful to catching bugs quickly.
@@adm3333 Lets clarify things a bit using a fake example. Imagine you have to test user registration case. A positive one. To check controller/service/db layer it is enough to implement one e2e/integrational test case. How many unit tests should be implemented for this scenario? I can assume at least 3.
@@aleksandrsavvopulo4510 At the point where you need to test a "user registration case" with three layers, in a proper TDD you'd already have a whole suite of unit tests covering all of controller, service and DB connection code. You would literally not be able to arrive at the 3-layer code architecture without writing all of them. Given all these tests already in place, functional test covering a "user registration" will be pretty straightforward to write and it will not be a *unit* test anyway. TDD assumes completely different kind of automatic tests from what you have in mind based on your comments above.
i have been watching his talks and it's all junk. yes, he isn't promoting bad advice per se, but he doesn't really give solid practical advice either. and his talks are usually filled with fluff. he's an out of practice programmer giving talks because there is demand for him. i am surprised how he made a career out of this, his book must have built a huge cult following. i actually like his history/science tangents and how they are great analogies to software, but without doing any new work, he is just a puppet spewing something you can find on wikipedia. except he will draw it out and make it sound profound because he has nothing else to work with.
First 16 minutes when he was rambling about the coin flipping which had absolutely nothing to do with the topic. nor did he try to relate that discussion to the topic. Secondly, real life software development s much different and under strict constraints than what he perceives it to be. It's good that a function or module should do only 1 task or related tasks but applying the same theory to a function read it programmers.stackexchange.com/questions/275646/is-the-single-responsibility-principle-applicable-to-functions
Mercede Have you ever worked in a "real life software development" environment? It's a nightmare PRECISELY because firms don't follow the SOLID principle. Have you ever had to maintain spaghetti code 10-100k lines long where classes and functions and methods have multiple responsibilities, arcane couplings, spooky actions from a distance, etc. Let alone having to hunt down dependencies hacked together for the wont of C-level managers. My guess is if you have, and support it, you are glutton for punishment, or dont value your time. Keep in mind he is also one of the original creators of AGILE development and a HUGE proponent of FP, which uses only functions instead of objects to implement logic.
Mercede there can always be too much of a good thing, SRP is no different. but personally i prefer to err on the side of SRP and related principles, and i wish other developers had the same approach. btw "Uncle Bob" isn't some sort of an academic theoretician as you seem to imply, given his bio it's safe to assume he knows a thing or two about "real life software development"
The intro had everything to do with the topic at hand. I knew exactly where he was going with it right away. If you've ever worked on a team that pays no mind to SRP you find yourself working within a code base at maximum entropy. It's a beautiful analogy.
![Eminem - Houdini [Official Music Video]](http://i.ytimg.com/vi/22tVWwmTie8/mqdefault.jpg)
Problem with S.O.L.I.D is everyone who teaches it uses abstract examples: "Person", "Animal", "Employee", etc. These relations are obvious to anyone, but not all programming relations are as intuitively recognized. I think people should start using examples from real world applications. Show pseudo-code of a theoretical power-point application, sales system, photoshop. Yes, showing OOP is easy when using things we already recognize as physical "objects", but this get much more complex in applications.
Joe Benge Start applying this principle in simple modules, then you'll start to understand on how to apply in complex modules. Please, don't get me wrong, this is a tip and the way I followed.
Yes, but we need someone to show us a big project sometimes to see it actually done.
its done in the same way. simple or complex, the principle is the same... especially single responsibility.
Agree to you try to watch learn code solid principles of Bob paid courses but totally worth
what is an acronym? it's a brand, it's catchy, it seems to have huge meaning packed into it because each letter is actually a word, woah!
SOLID is like someone giving one whole talk on "balance". would you watch a lecture on someone telling you how he is able to stand on one leg for a long period of time? how many lectures do you have to watch before you begin actually practicing balancing? can anyone teach you how to balance in a day? or is it a continual exercise that you get better and better at?
are there rules to balancing? sure you have to understand about gravity and maybe intuitively about fulcrum. but you learn by doing it. all of his talks are effectively useless, he's just riding his clean code book. you dont watch bill nye to learn physics, so you shouldnt watch bob martin to learn to code. if you want to watch to learn, you watch someone who actually codes and is in practice. i highly suspect this guy is out of practice.
i deplore this bob martin man, specifically because he has so LITTLE to say. but what can you do, right? there are kids and sometimes kids want to watch clowns. and who is going to ban that?
0:00 - Ice breaker - Entropy
6:14 - SRP, Views and SQL, Why separate things?
8:50 - Report generator example
11:41 - Responsibility for one person
13:14 - Mixing HTML and SQL example
14:13 - One change affecting other code
16:17 - Rigidity
17:20 - How can you separate the changes?
17:40 - Employee example
19:37 - Deceptive module; modules should know less about business objects
21:21 - Separate into smaller classes
21:50 - Roman numerals kata, TDD feels slow; comparison using TDD vs. no TDD
26:25 - Separate into smaller classes
30:05 - How many methods should a class have?
30:45 - The database is a detail; should be replaceable; our modules shouldn't care is we use SQL, NOSQL
34:41 - Business rules shouldn't belong on the database
36:10 - Symptoms of bad system design
38:10 - Forced to change in many places
39:25 - Fragility, touch a module and everything works, in a different part
43:00 - Mastermind
45:05 - Responsibilities breakdown
49:00 - Separating is hard
49:20 - Refactoring
50:30 - Separating code should be the last operation
Thank you!
I really appreciate his talks.. The fact he doesn't need slides or examples and can conceptually engage you in re-thinking design patterns is amazing.
Awesome!
My code at work is in maximum enthropy
It's not. It's in equilibrium until someone decides to come in and change it, be it a customer or whoever else.
You wish it'd be. Until someone else changes it. 😬
Great talks !
This sounds so much like Viewpoint analysis by Fukes and Finklestien back in the 80s
If every programmer (especially the one who called himself software architect) at least watched this lecture or better read his book (better first book on that path) before they started develop complex system how good life might be. Thanks for sharing!
Not all at, it would just raise the bar and then we would have to really up our game to be the top income brackets.
Luckily, as long as management focuses on going fast above all else, we won't have to worry about it.
@@daniels3980 Sometimes going fast depends on stability of the system.
One question related to identifying the people requesting the change. Where does the request for changes for Save() and FindByID() originate from? Sometimes new features introduce database schema changes. Sometimes performance optimization results in schema changes. Would it be correct to mention DBA as the source for change? Origin in the former case is end-user whereas in the latter, it is test team...
Heads up and tails down are the same thing right?
I caught that as well. I thought he was starting out on a trick question!
Physics isn't exactly his strong suit even though he wastes several minutes of every lecture he gives on it.
Wat?
So the answer should be 1000
Uncle Bob is so funny
And so serious... hahaha
Transactions really break the "my application doesn't know it's a (sql) database"... You can definitely isolate very well against the relational model in sql, but I have not found a good way to let an application rely on transactionality of db modifications when the db is not actually transactional...
If you could save yourself, you'd save us all!
I've written many .Net applications that used Oracle for the database.
Calling this Single Resposibility Principle instead of Single Role Principle is a billion dollar mistake.
This.
It's about a unique role and about a responsibility towards a user/code group (this agreeing united user/code group should be the one and only reason to change) and not about inner responsibility (cohesion) and Uncle Bob writes about this greatest misunderstanding of the principles in his book "Clean Architecture".
Even a simple primitive constant can violate the SRP if it's used by disagreeing user/code groups instead of playing just one role.
Hm, it seems that Mr. Martins understanding of entropy is a bit messed up as he said, that going back in time we should expect the Universe be in a higher entropy state. It is opposite, isnt it? Anyway, great talk.
The universe had a higher entropy in the past. It had a warmer temperature and also much smaller in size.
Heads up and tails down is the same state.
Some nasty bug was attracted to SRP @35:26 : ) Did you try to squash it ?
What ?
He will never reveal an SRP solutions that appears in 26:10 :-)
This is great but I'd rather see a more practical example of someone applying this logic. Does anyone have a suggestion?
If ever you work for public services in Europe you'll get multiple full scale examples !
Lol, I love Uncle Bob, but why does he always start off his talks about completely random physics topics? :)
Because he wants to remember us of the logic of physics and the importance of science. It let the smart persons say what if we add some science as an accelerator for programming?
Stupid persons say I just don't get it :)
Because people are sometimes late, so he warms things up with a brief, interesting story before getting to the main talk.
So, I generally love Uncle Bob (I have purchased all of his books), but this talk was pretty terrible. First quarter wasted to a discussion of physics, after that he is getting somewhere with a concrete example that he is about to show possible solutions for when all of a sudden he cuts off and starts talking about TDD and Katas and then he never gives any resolution to the example. I am a new developer and I would have really benefited if he actually showed some concrete solutions. I can infer what they should be, but what if my intuition is wrong and leads to bad code? I just want to know how he would have refactored the employee class...
+NicholsonLifting there can't really be a concrete example because there are too many. It's not really like an equation, it's more like a philosophy. You have to change the way you think about building systems so no thing is solely dependant on another class, rather you have either an interface or a generic class that facilitates the request. Example: USB is an interface, but can can have many uses. I hope that makes sense!
+NicholsonLifting, I totally agree! I love Uncle Bob, but this is the 5th talk of his that I've watched now, where he opens with an extremely long-winded and unrelated talk about physics! If I wanted to learn about physics, I'd go watch a Neil Degrasse Tyson or Lawrence Krauss talk.
That's the reason classes and systems become harder to maintain and why programming is so hard. Martin gave exactly what needs to understand the basic principle, his intro wasn't out of place, it was perfectly fit into its purpose. And yet you're asking for concrete example or concrete implementation. Use abstract thinking. Or any thinking.
Also, intro wasn't about physics. It was about programming industry. It was about computer programs. It was about single responsibility principle.
@@ropro9817 hows it long winded it is 6 / 50 min talk
its supposed to draw the viewers in and its for the live audience not you, you can skip past it
btw, tdd does not fit startups. its a madness to use tdd when you have short iterations and requirements changing often.
This is completely and totally false. Requirements changing often means you'll be refactoring often, which means you need very strong unit tests, which means using TDD.
@@adm3333 tests adds at least 30% of efforts to the development. You dont need 100% coverage at start. So cheaper solution would be e2e. That will give some guarantee that main functionality works. And that much much cheaper than tdd. Tdd in most cases is overkill.
@@aleksandrsavvopulo4510 I suspect that you have a different definition of unit test. If your idea of a unit testing includes rampant mocking of internal dependencies and directly testing code in modules other than through entry points, then yeah, those tests suck, but they suck regardless of whether you're a startup or not.
Proper module-level TDD unit tests are cheaper than E2E tests and more useful to catching bugs quickly.
@@adm3333 Lets clarify things a bit using a fake example. Imagine you have to test user registration case. A positive one. To check controller/service/db layer it is enough to implement one e2e/integrational test case.
How many unit tests should be implemented for this scenario? I can assume at least 3.
@@aleksandrsavvopulo4510 At the point where you need to test a "user registration case" with three layers, in a proper TDD you'd already have a whole suite of unit tests covering all of controller, service and DB connection code. You would literally not be able to arrive at the 3-layer code architecture without writing all of them. Given all these tests already in place, functional test covering a "user registration" will be pretty straightforward to write and it will not be a *unit* test anyway. TDD assumes completely different kind of automatic tests from what you have in mind based on your comments above.
Single Responsibility Principle - Talk about software design, and not physics, in a lecture about software design.
I know he's revered in the community but I find his presentation style unbearable.
Agree, there's too much filler. He spends 20 mins making the exact same point. This whole talk could be condensed down to 15 mins or less.
@@BBB-zy6er But you don't get redundancy in a lecture. This is a just a semi-casual talk, relax.
@@BBB-zy6er The aim of a lecture is usually to deliver the maximum amount of info in the shortest amount of time. This isn't a lecture.
How not to give a presentation 101. Skip to 17:05, watch 1 minute, then delete this video. Trust me, there's nothing else valuable in here.
Really? I watched few of his talks and they are entertaining and informative at the same time. Perfect for after work.
i have been watching his talks and it's all junk. yes, he isn't promoting bad advice per se, but he doesn't really give solid practical advice either. and his talks are usually filled with fluff.
he's an out of practice programmer giving talks because there is demand for him. i am surprised how he made a career out of this, his book must have built a huge cult following.
i actually like his history/science tangents and how they are great analogies to software, but without doing any new work, he is just a puppet spewing something you can find on wikipedia. except he will draw it out and make it sound profound because he has nothing else to work with.
@@mescellaneous Damn, you salty
First 16 minutes when he was rambling about the coin flipping which had absolutely nothing to do with the topic. nor did he try to relate that discussion to the topic. Secondly, real life software development s much different and under strict constraints than what he perceives it to be. It's good that a function or module should do only 1 task or related tasks but applying the same theory to a function read it programmers.stackexchange.com/questions/275646/is-the-single-responsibility-principle-applicable-to-functions
spot on! I
Mercede Have you ever worked in a "real life software development" environment? It's a nightmare PRECISELY because firms don't follow the SOLID principle.
Have you ever had to maintain spaghetti code 10-100k lines long where classes and functions and methods have multiple responsibilities, arcane couplings, spooky actions from a distance, etc. Let alone having to hunt down dependencies hacked together for the wont of C-level managers.
My guess is if you have, and support it, you are glutton for punishment, or dont value your time.
Keep in mind he is also one of the original creators of AGILE development and a HUGE proponent of FP, which uses only functions instead of objects to implement logic.
Mercede there can always be too much of a good thing, SRP is no different. but personally i prefer to err on the side of SRP and related principles, and i wish other developers had the same approach.
btw "Uncle Bob" isn't some sort of an academic theoretician as you seem to imply, given his bio it's safe to assume he knows a thing or two about "real life software development"
The intro had everything to do with the topic at hand. I knew exactly where he was going with it right away. If you've ever worked on a team that pays no mind to SRP you find yourself working within a code base at maximum entropy. It's a beautiful analogy.
bla bla bla, rant, rant, who are you?