Deep Class
最近看了个有趣的talk："A Philosophy of Software Design" by John Ousterhout。
如果要选一个概念，贯穿整个计算机系统，应该选哪个呢？
John Ousterhout问过Donald Knuth，Knuth给的答案是layers of abstraction。
John Ousterhout自己觉得是problem decomposition，要注意隔离复杂度。
最近看了个有趣的talk："A Philosophy of Software Design" by John Ousterhout。
地址：https://www.youtube.com/watch?v=bmSAYlu0NcY
记录几个有趣的点。
抽象还是分解
如果要选一个概念，贯穿整个计算机系统，应该选哪个呢？
John Ousterhout问过Donald Knuth，Knuth给的答案是layers of abstraction。
John Ousterhout自己觉得是problem decomposition，要注意隔离复杂度。
关于Deep Class
很直观的表述方式。应该尽量写Deep Class。
对比Java的IO接口和Unix IO接口：
|
1 2 3 |
FileInputStream fileStream = new FileInputStream(fileName); BufferedInputStream bufferedStream = new BufferedInputStream(fileStream); ObjectInputStream objectStream = new ObjectInputStream(bufferedStream); |
|
1 2 3 4 5 |
int open(const char* path, int flags, mode_t permissions) ); int close(int fd); ssize_t read(int fd, void* buffer, size_t count); ssize_t write(int fd, const void* buffer, size_t count); off_t lseek(int fd, off_t offset, int referencePosition; |
闲扯decomposition
① John Ousterhout是Raft作者的导师 & John Ousterhout觉得要注重problem decomposition。
② Raft声称其特点是understandable。
③ 有不少熟悉Multi-Paxos和Raft的人，并不满意②的说法，因为他们觉得Raft NOT convincible。
④ 显然③是对的。
⑤ 我觉得，复杂度有时候是根植于问题本质的，无法消解。
⑥ 所幸工程上⑤这种本质复杂的东西并不多，绝大部分复杂度应该都是自己作出来的。
⑦ 这些自作的复杂度会导致：想不清楚细节、迟迟不能稳定、改动越来越难。
⑧ 因为⑦，这个视频还是值得一看的，当然肯定也不能把它当银弹，因为软件工程领域没有银弹。