Re:Facts every web dev should know before they burn out and ...
by selfhoster11 on Thursday October 21, 2021 @06:08AM
(#28942436)
I believe that code should be neatly organised, though I have no preference about how this is accomplished. What would you suggest I should do, if not split classes?
Re:Facts every web dev should know before they burn out and ...
by ratww on Thursday October 21, 2021 @06:32AM
(#28942578)
You should split classes! But only where it makes logical sense, where there is a clear logical boundary.
Splitting code as a way to visually organize code can lead to tight coupling, which tends to be worse than large classes.
If you split a class but there’s still multiple “points of contact” between both, it wasn’t a good split at all.
Re:Facts every web dev should know before they burn out and ...
by selfhoster11 on Thursday October 21, 2021 @06:48AM
(#28942677)
People split classes for visual reasons?
That sounds unwise. I only ever split because the class is getting too large, or because some functionality is better off being moved to its own class. And those other classes also should preferably only have one or two methods exposed to the outside, there's nothing worse than a large surface area unless it's a library class.
Re:Facts every web dev should know before they burn out and ...
by ratww on Thursday October 21, 2021 @08:00AM
(#28943167)
Yep, you are completely right, this is extremely unwise. Problem is, a lot of material aimed at beginner developers basically instructs that. Also a lot of linter documentation shepherds users into doing it (I'm thiking of some Ruby linters here).
> there's nothing worse than a large surface area unless it's a library class
Yep, exactly. Even big classes are better than tightly-coupled classes with large surface area.
Oh yeah. But I've seen this also happening in frontend libraries, and sometimes even inside monoliths.
I find that inexperienced developers tend to break up services/libraries/classes purely because they believe that "code should be neatly organized", not because there is a logical boundary between two parts of a system. Thus, we get lots of tight coupling, chatty microservices, and 20 lines of imports at the top of the file.
I find that A Philosophy of Software Design by John Ousterhout [1] has a good rule of thumb: classes (and services, libraries, repos, applications) should be "deep, not shallow". The "surface" (aka the part that touches external components) should be as small as possible, while the internals should be larger. Of course that doesn't sit well with people looking to "neatly organise code".
[1] https://www.goodreads.com/book/show/39996759-a-philosophy-of...