3 ms·
I don't think the author made a very good case for this. The case made on readability. But indirection is very common that if you can't read a piece of code wit
by keithnz 7y ago
I don't think the author made a very good case for this. The case made on readability. But indirection is very common that if you can't read a piece of code without having to drill into the implementation of every function, lifes going to be quite painful. Depending on your language and editor / IDE, seeing implementation is often trivial. The only case, I see, for inlinig is where the pieces of code are very cohesive and tied together and will only be used as a single unit. Maybe that's what the author was trying to get at, don't break atomic units of code up.
- mberning 7y agoI agree. The author actually makes a decent case for using this pattern though. I think it comes down to the skill and clarity of thought of the developer. If this pattern is used judiciously and the methods are named well then it adds very little cognitive overhead. Also, it is very refreshing to read about and discuss actual development.
- keithnz 7y agoFor sure, the pattern is good, having atomic units of code fragmented into pieces is not nice. This is essentially part of the Single Responsibility Principle, if things are together to suppport a single responsibility, don't fragment them. The trick is knowing "what IS the responsibility of this thing?" and not over doing it.