←back to thread

361 points mmphosis | 4 comments | | HN request time: 0.843s | source
1. Barrin92 ◴[] No.42166983[source]
Pretty substantial disagree with the second half of 4. and 5.

>If the component is big, then you introduce more complexity[...] If a particular function doesn't fit anywhere, create a new module (or class or component)

This smells like the agile/uncle Bob "every function should be four lines" school of thought which is really bad.

Paraphrasing Ousterhout's book, it's the other way around, when components are big and contain significant implementation you're hiding information and reducing complexity, which is the purpose of good program design. When your component/object/module is just surface you've basically done no work for whoever uses your code. I see it way too often that people write components that are just thin wrappers around some library function in which case you haven't created an abstraction, you've just added a level of indirection.

If a function does not fit anywhere that's a strong indication that it shouldn't be a separate function, it's likely an implementation detail.

replies(1): >>42168099 #
2. brewmarche ◴[] No.42168099[source]
Are you talking about this book: A Philosophy of Software Design? Can you recommend it?

I am looking for rebuttals of this naïve Uncle Bob style and while I like the content of Casey Muratori, he doesn’t resonate with more corporate people.

replies(1): >>42168227 #
3. Barrin92 ◴[] No.42168227[source]
Yup, it's a recommended read. It's pretty short, 160 pages or so and not at all difficult, the title makes it sound a bit grander than it is.
replies(1): >>42172505 #
4. brewmarche ◴[] No.42172505{3}[source]
Will check it out, thanks