In my experience, most software design principles that are taken to the extreme miss the point, or in the worst case even achieve the opposite of what was their original motivation.
Ousterhout acknowledges this in the introduction as well. He writes: "When applying ideas from this book, it's important to use moderation and discretion. Every rule has its exceptions, and every principle has its limits."
The fundamental motivation of the principles he lays out is stated in the second chapter as "how to design software systems to minimize their complexity".
At the same time, the author recommends that both public and non-public interfaces should be deep. Everything should provide something deep, complex and powerful. Small classes, short methods are not such things.
My understanding of the book differs from a bit from this paraphrase.
In the chapter 4 "Deep Modules" Ousterhout distinguishes interface from implementation. Maybe you can clarify if whether I understood you correctly, but I would read "non-public interfaces" as implementation.
I don't think that the argument for deep modules also implies that the implementation of their interface should come in form of a single long method.
Indeed, the term modules is not specific to the semantics of a concrete programming language, and for smaller constructs like pure functions or single methods of a class, a recursive application of the principle that "module should be deep" without any discretion, might end up in a bad place with overly long methods. On the other hand, methods can become so small that they stop providing any abstraction at all, which is also no desirable property.
I think an essential aspect of software design manifests in the necessity to balance such opposing forces with the long term health of the overall system in mind.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my experience, most software design principles that are taken to the extreme miss the point, or in the worst case even achieve the opposite of what was their original motivation.
Ousterhout acknowledges this in the introduction as well. He writes: "When applying ideas from this book, it's important to use moderation and discretion. Every rule has its exceptions, and every principle has its limits."
The fundamental motivation of the principles he lays out is stated in the second chapter as "how to design software systems to minimize their complexity".
My understanding of the book differs from a bit from this paraphrase.
In the chapter 4 "Deep Modules" Ousterhout distinguishes interface from implementation. Maybe you can clarify if whether I understood you correctly, but I would read "non-public interfaces" as implementation.
I don't think that the argument for deep modules also implies that the implementation of their interface should come in form of a single long method.
Indeed, the term modules is not specific to the semantics of a concrete programming language, and for smaller constructs like pure functions or single methods of a class, a recursive application of the principle that "module should be deep" without any discretion, might end up in a bad place with overly long methods. On the other hand, methods can become so small that they stop providing any abstraction at all, which is also no desirable property.
I think an essential aspect of software design manifests in the necessity to balance such opposing forces with the long term health of the overall system in mind.