tag:blogger.com,1999:blog-4632619500491960788.comments2024-02-07T11:18:15.057-05:00Software on the BrainJoseph Lynchhttp://www.blogger.com/profile/11886779384421780164noreply@blogger.comBlogger48125tag:blogger.com,1999:blog-4632619500491960788.post-24026039458606890792022-04-18T04:58:33.193-04:002022-04-18T04:58:33.193-04:00Thanks :)Thanks :)Jeremiah Flagahttps://www.blogger.com/profile/14101574646967614301noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-88407123487730867292022-02-15T15:23:02.097-05:002022-02-15T15:23:02.097-05:00Thanks for the explanation. I have a graphical wa...Thanks for the explanation. I have a graphical way to look at cohesion and separation, using a spreadsheet analogy. https://kenpugh.com/blog/the-spreadsheet-conundrum/ You always have multiple ways to do something and using a simple table without getting into the code can help in finding those multiple ways. As Jerry Weinberg said, "If you can't come up with three solutions to a problem, you don't understand the problem" <br /><br />Kenhttps://www.blogger.com/profile/08891390578699471167noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-40717525442314166892022-02-11T12:56:09.519-05:002022-02-11T12:56:09.519-05:00"My experience is that the need to separate t..."My experience is that the need to separate things is discovered incrementally as the system evolves. Proactive separation based on a theoretical need usually isn't worth it because it's hard to predict the future."<br /><br />---<br /><br />This statement aligns my understanding! Again, much thanks for all your responses. <br /><br />Truly appreciate it and I will do my best to share this understanding to my workplace also back to community!Erick Sumargohttps://www.blogger.com/profile/08929175171575049989noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-64582716892673590042022-02-11T10:32:14.655-05:002022-02-11T10:32:14.655-05:001.) Yes. Best to think of it as an executive or f...1.) Yes. Best to think of it as an executive or functional group that will make a decision independently of another group. For example, the CFO (the leader of Finance department) may make decisions independently of the COO (the leader of the Operations group) and they might have their own business logic on a shared entity (e.g. employee). If that's the case you'd want to consider separating out the logic on an employee that could differ based on their different business rules.<br /><br />2.) I don't think your example merits separation unless I am missing something.<br /><br />My experience is that the need to separate things is discovered incrementally as the system evolves. Proactive separation based on a theoretical need usually isn't worth it because it's hard to predict the future. I think the best thing to do would be to read Uncle Bob's post carefully. I think you'll see that the SRP as he intends it is not something you need to think about everyday.<br /><br />Post: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.htmlJoseph Lynchhttps://www.blogger.com/profile/11886779384421780164noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-69310121446624023692022-02-10T21:12:17.980-05:002022-02-10T21:12:17.980-05:001. Oh so for overall, I should see an "owner&...1. Oh so for overall, I should see an "owner" as an entity / group of members that share same interest rather than as a granular individual of instance?<br /><br />2. If so, let's refer back to my module features example. If at some point, feature_edit_profile requires to add some additional logic to the repo to satisfy what it needs, that's when I should separate it with different repo to satisfy its particular req. Correct me?Erick Sumargohttps://www.blogger.com/profile/08929175171575049989noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-43796061496579688282022-02-10T10:40:08.807-05:002022-02-10T10:40:08.807-05:00I could be missing something but I don't see a...I could be missing something but I don't see anything problematic, from a design perspective, with what you're describing. One user object, one user repo would be fine.Joseph Lynchhttps://www.blogger.com/profile/11886779384421780164noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-33225933223011741342022-02-10T07:59:15.194-05:002022-02-10T07:59:15.194-05:00Much thanks for the reply Joseph!
So I'm actu...Much thanks for the reply Joseph! <br />So I'm actually a mobile apps engineer. In my marketplace app, I have a couple of module features. Let's say:<br />- feature_about_me (to display user's summary profile)<br />- feature_edit_profile (to display and edit user's profile)<br />- ...<br /><br />All of these features need - well, the user's profile information. And I have a repository that can provide the profile data. Ofc I can make them depend on the repo to satisfy what they need (hence, they become "owners". Correct?). No problem.<br /><br />But with this post, I should have violated the actual SRP principle by turning the repo has more than 1 owners, right? So this example wraps-up my dilemma referred from my previous comment. <br />Erick Sumargohttps://www.blogger.com/profile/08929175171575049989noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-33836622908524258512022-02-09T12:32:16.258-05:002022-02-09T12:32:16.258-05:00Like all good design question I think "it dep...Like all good design question I think "it depends". A user is a horizontal concept across a system. Yes, 10 business owners might have a stake in it but I think it requires a "decider". In this case it might be a VP Eng/CTO/CIO type. What are the examples of how the same conceptual logic differs across the N business owners?Joseph Lynchhttps://www.blogger.com/profile/11886779384421780164noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-1743451417050653242022-02-08T22:03:51.315-05:002022-02-08T22:03:51.315-05:00For years, I always fail try defining what is &quo...For years, I always fail try defining what is "Single"-RP. Turns out a bias understanding. Much thanks for this enlightment post!<br /><br />Now I want to bring a practical example to be discussed. Given that I have a repository instance that fetch from a datasource and returns a User profile. Now let's say I have 10 owners that have EXACTLY the same use case.<br /><br />If I make those 10 owners depend on this repo, I clearly have violated the actual SRP principle (Yes?). But if I duplicate the same repo logic to satisfy the actual principle (one-to-one relationship), I think this is not being practical. A price to pay to maintain them and someone from workplace must refer me as a "dumb" and such a fanatic-being of a principle.<br /><br />What is your thought regarding this?Erick Sumargohttps://www.blogger.com/profile/08929175171575049989noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-59029664160259916882022-02-03T12:00:19.942-05:002022-02-03T12:00:19.942-05:00Who's "fault" it is is not terribly ...Who's "fault" it is is not terribly interesting/relevant to me. I was just pointing out that people often mis-apply the SRP, according to its latest definition anyway. The explanation of it was abbreviated. The post that it links to (from Bob) explains it in more detail: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html. Hope that helps.Joseph Lynchhttps://www.blogger.com/profile/11886779384421780164noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-17828348402980267592022-02-03T11:54:25.518-05:002022-02-03T11:54:25.518-05:00I think we agree more than it might seem.
Let'...I think we agree more than it might seem.<br /><br />Let's say there is the V1 explanation and the V2 explanation. The first definition goes back to his 2003 book and says "a class should have only one reason to change". He frames it as a take on explaining cohesion ("the functional relatedness of the elements of a module"). Link is below. Its explanation is very simple a message of separation of concerns and cohesion, using various examples that if dimension x can/does change independently from dimension y and a class deals with them both, they ought to be split up. The examples he gives are reasonable and most people would agree on (e.g. separating business logic from persistence logic for an employee class).<br /><br />The issue I see is that people use it to an extreme and separate things so much that the class has lost cohesion. A silly example: an employee object calculates a current age and also calculates tenure at the company. Changes to that logic are clearly two reasons to change so clearly they must be proactively broken up into separate classes, right? I've seen people make arguments like this ad-absurdum to justify designs that have too many moving parts. And I think it's because you can naively interpret "a reason to change" at a tiny level of granularity.<br /><br />Years later, V2 of the principle comes along (which I am guessing is due to the misapplication of V1) which describes it as being related to people or areas of functional ownership. That's a very narrow definition (and subset of V1) that, while useful, isn't needed everyday. I suspect the second definition emerged because people were mis-applying the concept at small levels of granularity. Personally I see the V2 definition to be a natural consequence of DDD ideas and the V1 definition as the very definition of cohesion.<br /><br />p. 95 of book http://journals.mountaintopuniversity.edu.ng/Software%20Engineering/Agile%20Software%20Development,%20Principles,%20Patterns,%20and%20Practices%20(%20PDFDrive%20).pdfJoseph Lynchhttps://www.blogger.com/profile/11886779384421780164noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-25884356837808256522022-01-26T14:07:29.580-05:002022-01-26T14:07:29.580-05:00Yay, SRP is about people now! But it's a mista...Yay, SRP is about people now! But it's a mistake ...<br />How many people do you know? 100? 200? 1000? Imagine that each one is an "Actor" (whatever that is, exactly). Do you have 100, 200 or 1000 classes then, because that's sufficient for "being responsible to one actor"? Certainly not. A large app has tens of thousands classes. But why, if not for SRP reasons?<br />Even Uncle Bob was not smart enough to find a good definition for more than 6 years - and still hasn't, IMHO. In contrast: by changing the definition, he brought more confusion and need for education.Anonymoushttps://www.blogger.com/profile/17991507131632884678noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-20156059542428939652022-01-23T11:17:40.125-05:002022-01-23T11:17:40.125-05:00Excellent read and something I have tried to expla...Excellent read and something I have tried to explain to people many times. It is a tricky thing to explain but I think this article does a pretty good job of it. Single responsibility does not mean do one thing, it means the code should be responsible to a single owner, aka a single point of change.Nathanhttps://www.blogger.com/profile/03179298878053110287noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-57200765798050209372022-01-23T11:14:34.550-05:002022-01-23T11:14:34.550-05:00This is a balanced review of the SRP and it demons...This is a balanced review of the SRP and it demonstrates your maturity in applying software design principles. I could have loved to see how you reviewed SRP with respect to other SOLID principles. I always find it useful when I look at these principles holistically. May be an idea for your next blog post.Julius Ahttps://www.blogger.com/profile/00735231155775969553noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-55137810256584952322022-01-23T09:39:02.868-05:002022-01-23T09:39:02.868-05:00Well, but then - who's fault is it that the pr...Well, but then - who's fault is it that the principle is so widely misunderstood? Maybe the definitions, explanations and examples should be more clear? By the way, with all due respect, I don't understand your definition of SRP presented in the article... like... at all.František Žiačikhttps://www.blogger.com/profile/02607379209348298311noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-69999398188585770412022-01-23T08:46:16.150-05:002022-01-23T08:46:16.150-05:00Well written!Well written!Venkat Ramakrishnanhttps://www.blogger.com/profile/03704789182233277452noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-88289283195601566192020-01-01T23:14:55.677-05:002020-01-01T23:14:55.677-05:00Thank you for sharing this knowledge in a blogpost...Thank you for sharing this knowledge in a blogpost.Really simple and even more effective and this worked great, very useful tipsdhishageethahttps://www.blogger.com/profile/17744856542518248752noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-15576253416227469782016-04-22T09:48:32.030-04:002016-04-22T09:48:32.030-04:00Joseph: I also knew Joe and agree he was a wonderf...Joseph: I also knew Joe and agree he was a wonderful, giving person. His unexpected passing left us all feeling we had know a very special man.Anonymoushttps://www.blogger.com/profile/02302053236899147156noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-7491243396488454232016-04-20T07:00:09.354-04:002016-04-20T07:00:09.354-04:00Thank for sharing this about Joe. This is who he ...Thank for sharing this about Joe. This is who he was. A generous giver. <br /><br />To all those he helped, please, pay it forward. This IS Joe's legacy! Jim Healyhttps://www.blogger.com/profile/02083316634729023606noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-69445565199312153712016-04-09T19:17:51.036-04:002016-04-09T19:17:51.036-04:00That was very eloquent Joseph. I only knew Joe su...That was very eloquent Joseph. I only knew Joe superficially (unfortunately) through TENG. He was an easy man to respect and admire. My condolences to his family and thank you for sharing. Anonymoushttps://www.blogger.com/profile/06141395194957049963noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-55486866050013217752016-04-09T11:56:54.127-04:002016-04-09T11:56:54.127-04:00+1+1jonhttps://www.blogger.com/profile/12613257174589409034noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-63422640203073123442016-04-08T16:43:09.955-04:002016-04-08T16:43:09.955-04:00Josh, condolences for your family's loss. Your...Josh, condolences for your family's loss. Your dad was a consummate professional, mentor to many, and example of selflessness in the tech community. <br /><br />Joseph, thanks for sharing your reflections. Inspiring story, well told, and fitting tribute to a great guy.Chuckhttps://www.blogger.com/profile/02735882699255240712noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-68542618930537186992016-04-08T15:28:30.037-04:002016-04-08T15:28:30.037-04:00You're welcome, Josh. My heart goes out to yo...You're welcome, Josh. My heart goes out to you and your family. I hope that through these stories you can see how much impact your father has had on the lives of other people and that his positive example will continue to inspire us to be kinder to one another.Joseph Lynchhttps://www.blogger.com/profile/11886779384421780164noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-36317684030490023972016-04-08T15:25:07.077-04:002016-04-08T15:25:07.077-04:00Thanks Shana! I'm actually reading the book n...Thanks Shana! I'm actually reading the book now. It's part of what helped me to see the importance of this experience.Joseph Lynchhttps://www.blogger.com/profile/11886779384421780164noreply@blogger.comtag:blogger.com,1999:blog-4632619500491960788.post-7389909921251154392016-04-08T10:36:49.798-04:002016-04-08T10:36:49.798-04:00Thanks for sharing this with me, Kristen. As his s...Thanks for sharing this with me, Kristen. As his son I've heard countless stories like this, and I'm looking forward to helping people like he did in my professional future. This is a nice story. Thank you Joseph and good luck to you. - Josh TaitJosh Taithttps://www.blogger.com/profile/05328623026090776356noreply@blogger.com