Comments

You must log in or register to comment.

IsntDoingScience t1_ir3wjjq wrote

As someone still in my first year of being a professional computer hammer, this is helpful to look at.

8

Eluvatar_the_second t1_ir40zyh wrote

Not sure what's so interactive about this, maybe it's because I'm on mobile but couldn't this have just been done with pictures?

169

Cogadh t1_ir45y9u wrote

This was a great read, thank you! Separation of concerns, or rather lack thereof, has been the downfall of way too many orgs. Hurts thinking about all the times I've seen "unintended consequences"

5

Cogadh t1_ir4663c wrote

You're not wrong to ask it, but how many people are just as guilty of "skimming"? None of us ever have enough time, but patience to read thoroughly directly impacts comprehension

0

caeptn2te t1_ir49t8i wrote

I find the idea of presentation is great! It helps organizing the stuff in my brain.

0

polarphantom t1_ir4bvdm wrote

Shame that mobile responsiveness wasn't a principle for this site

35

PoorlyAttired t1_ir4d44q wrote

That's useful, though the example for interface segregation could be tweaked because I appreciate that both my laptop and phone are charged by USB-C.

3

29979245T t1_ir4f3y2 wrote

It might be referring to the fact that the pictures are made in some kind of cute drawing engine that records every shape and penstrokes and allows them to be manipulated in a pretty intuitive way. So you could easily redraw part of one if you thought it was a bad explanation, for example...except they're locked in readonly mode and I don't even see a way to make a copy to play with.

8

daedalus91 t1_ir4ij0a wrote

I've read the article. Can you elaborate on why is OP's example wrong?

So according to the article, it's all about the people requesting the changes. Spoon users try to use that spoork, and they realize it's not deep enough to spoon a soup. The developer redesigns it, makes the spoork deeper to enable it to spoon a larger amount of soup. Then the fork people try to stick their vegetables onto their spoork, but now due to the increased curvature of the spoork, it isn't straight enough, and the vegetables will fall apart and won't stick onto the spoork.

If you create a separate spoon and a fork, each user has their perfect tool.

9

Rwagstaff84 t1_ir4th5x wrote

Long time software developer and I get all these solid concepts but …. it doesn’t really change how I write code. I just write what I think is best based on experience. I never stop and think “does this meet the liskov substitution principle” or any of the other SOLID principles. Why is this brought up as the gold standard so much? Just seems like a way to claim you are a good coder because you “understand” solid. Is that just me? coding is so much more than just 5 generic concepts that you probably do almost always by default by following good patterns.

24

trekhleb OP t1_ir4uskq wrote

Yeah, the interactivity is pretty minimal, but it is still there in form of "Click to go deeper to the nested image with further details".

You're also right that all illustrations could be put on one page. But with the current approach, there is a possibility to add more details to the nested pages (to each S O L I D letter separately) without making the entry page bulky.

−4

trekhleb OP t1_ir4ve77 wrote

Yes, that's true that going back and forth not always convenient. I was trying to find this balance between "Staying focused on one principle at a time" and "Having all info be easily accessible at glance". Probably I didn't find the perfect balance yet :D

But, there is also the extensibility aspect. With the current approach, I may add more details to each letter in the future while keeping the entry page still readable. Technically it is possible to even add more nested sub-sketches to each letter if needed

13

trekhleb OP t1_ir4w2ls wrote

I guess the illustration with the "Spoon" + "Fork" instead of the "Spoork" still works, doesn't it? I mean if you want to change the "Spoon" functionality you just change the "Spoon" but not touching the "Fork", whereas the "Spoork" is going to be changed for two different reasons: when we want to change either the "Spoon" functionality or the "Fork" one.

3

trekhleb OP t1_ir4wr7e wrote

If you mean the "Fit to screen" zooming feature it is there (bottom right corner).

But if you're talking not only about scaling but also about re-arranging the sketch elements based on the screen size (in a classing web-app manner), then yes, it doesn't work.

This is a bit challenging to do for the free-hand drawing of absolutely-positioned and scaled elements since the app might not have enough context of how to re-arrange. I.e. there is a free-form arrow that goes from the exact word of the sentence to the exact Attachment of the Mixer (it is not clear how to redraw it from horizontal to vertical form-factor).

−3

MikeCampo t1_ir4x1vj wrote

SOLID is a bunch of bs.

4

Lampshader t1_ir4x3tr wrote

> 5 generic concepts that you probably do almost always by default

You probably do. I assure you that not everyone does, and giving these concepts names and descriptions is a good way to teach those who don't just intuitively "get it"

12

ghostella t1_ir4zcxk wrote

Weird that it appears that you can click on the various images but then it just displays an attached "open" button that you then have to click on again. Seems like it's made for the person designing vs the consumer.

20

RockstarArtisan t1_ir52lwr wrote

This is not a programming subreddit, but I assume you're familiar with the subject.

The job of a book author and advice merchant is to convey their advice in a manner that people can follow. People who are bad at this shouldn't be selling the advice. In this case, the problem isn't the writing style, it's just that there's nothing behind it.

Have you seen how "principled" this principle is? The author struggles to come up with the description himself. In his videos he says stuff like "Single responsibility principle is actually not about single responsibility, it's about a single reason for change" (I guess he did change his blog to say it's both now). This is the vaguest shit possible. Basically, Martin is a boomer consultant, who makes up acronyms to sell his shit. He needed some rules to make a nice acronym, so he picked 5 things arbitrarily, one of these happened to be "make stuff simple, not complicated". This is clearly meaningless padding, so he needed to convert this rule to be something that people will think is insightful - he came up with "single responsibility" which is the same non-advice, just with more plausible deniability.

I'm tired of having to write the same shit over and over again whenever another person get's caught up in this and posts on the programming subreddits about it so here's my latest brief description: https://old.reddit.com/r/programming/comments/xvu3gc/solid_principles_sketches/ir3uhyx/

7

RockstarArtisan t1_ir53gm6 wrote

No, there's just no insight in the principle whatshowever (see my other comment in this thread). This is engineering, not bible studies, if you need to repeat the wording exactly for it to sound convincing, there's probably an issue with the advice.

7

Ok-Butterscotch-6829 t1_ir56t5n wrote

This is actually really helpful. I’m starting to interview again and want to be able to intelligently answer using SOLID principles.

1

TheBeardofGilgamesh t1_ir5c9yr wrote

Worst code based I have ever encountered where people with a Clean Code book on their desks. Uncle Bob has no real experience in software development he just does the conference circuit and gives lectures.

9

RockstarArtisan t1_ir5q7om wrote

Well, it is widely known and established, but many people disagree about being good. Some of the advice is applicable in the context of a framework, but the author insists it should be used everywhere which results in bloated designs that people hate. The popularity of this in the Java community is mostly what's responsible for all the hate Java gets online - bloat, overabstraction, complicated designs exemplified by the most SOLID frameworks of them all - Spring - with it's AbstractSingletonProxyFactoryBean https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html

7

jobe_br t1_ir5rts1 wrote

The analogy is gonna be strained, but the real problem is the way SRP is stated as “only one potential change in the software’s specification” - this is not person centric. The way OP started this is more the way SRP was initially misinterpreted as a module should do one thing and only one thing. That’s actually more the Unix cli philosophy of “do one thing and one thing well” — but it’s not SRP.

Internally, we don’t try to pre-determine if a module follows SRP, we use actual changes being made to the system to identify modules that are changing as a result of different actors/people. We then refactor a module to split it so that it once again is aligned to one axis of change.

2

TheGerk t1_ir5sa78 wrote

Yeah. Maybe I just have a bone to pick, but I've always thought solid was pretty awful programming. There's some good ideas in there, but largely I've seen this make code bases worse.

3

jobe_br t1_ir5slha wrote

You’re going to have a strained analogy either way, but you might be able to come up with something that is more person centric. Your analogy focuses on the functionality of the spoon, fork, and spork, not the person’s needs - I could argue that a single person’s concerns are encapsulated by the spork, and as such it doesn’t need to be split up. Realistically, the existence of the spork gives credence to this - it wouldn’t exist if a separate spoon and fork were superior for all user needs.

Definitely change the text, though, either way.

1

ghostryder333 t1_ir6d7b7 wrote

I don't want to come off as offensive, but I believe if you don't just "get it" intuitively when writing code you're not gonna be able to work in the industry.

After all you still want to be able to read your code as it grows. You codebase will become more complex with each passing day, and if you don't actually get an intuitive grasp on how to structure things you'll become unable to maintain your code pretty soon.

−3

billwoo t1_ir6d8tw wrote

Don't overdo it. I guess it depends what sort of company you are applying to, but describing every answer in terms of SOLID will make it sound like you just discovered SOLID and think its the answer to everything.

3

Ok-Butterscotch-6829 t1_ir6ds9t wrote

There’s so much conflicting advice in programming I don’t know who and what to believe anymore. 🤷‍♂️ It seems to me that much of the time it’s just programmer’s own opinions. 🤷‍♂️

1

billwoo t1_ir6e306 wrote

Well we can ignore what the author insists on, and just use them as handy short hands for describing architecture decisions. All the principles are sound architectural advice without further context, but software design is mostly striking a balance between pragmatism and "perfect" architecture (extensibility, generality, low coupling etc.). That some Java libraries get that wrong isn't really evidence that "SOLID is a bunch of bs".

Only things that nobody uses don't get complained about.

1

mouse_8b t1_ir6q00h wrote

If it's your only book, yeah it's lacking. It doesn't teach how to be a good developer. But as a self-taught coder, having a reference like that was useful to increase my code quality and readability.

1

mouse_8b t1_ir6qkll wrote

You figured it out. There are so many aspects of software to balance, that it depends on what you are focused on as to what the best way forward is. And in many cases it's not the best, just good enough.

1

TheBeardofGilgamesh t1_ir7227x wrote

It’s less his technical ability that I question, it’s his advice for designing maintainable code bases. How can someone who has not worked on large code bases or large teams have the experience of trail and error know how well his methods work in practice. It’s like if a person wrote a book on commanding an aircraft carrier yet has no experience in the navy.

3

TuringC0mplete t1_ir752yi wrote

I preach SOLID pretty hard, but I think after a certain point it just becomes second nature and a "Yeah, that's just how you do it" kind of mindset. Not all of these principles are applicable to every scenario, but for the most part they're a good guide to writing clean code. Some languages don't even have interfaces to do a lot of SOLID things with (looking at you, python -.-)

But I agree that just because you understand the concepts doesn't mean you know how to affectively apply them. Hell, even for preaching them so much, the architect on my team explained to me a few months ago how I was using LSP completely wrong.

Ultimately to me, it's a great teaching tool; but you definitely need to know when to apply it.

1

feinerSenf t1_ir789ad wrote

Hi what library are you using for the free drawing implementation?

1

Adverpol t1_ir7d6pw wrote

The thing is that if you focus on solid it's easy to forget that often you shouldn't have had inheritance in the first place, that's my problem with it anyway. OOP is a tool that should be used when appropriate, which for me means when you actually need polymorphism e.g. store a list of different types of entities in a list.

2

NerdFoundryGaming t1_ir7dsj8 wrote

I found this UI to be very difficult to navigate.

It'd be better off as a proper slideshow. Literally no reason to have a weird breadcrumb navigation with movable entities on screen that serves no purpose other than to confuse the user as to what is even going on. Also, really hated the font used.

But the content was simple and decent.

2