灵活的粘合层

明确输入，我实际体会的就是方法参数
1是对象 （category） 这种形式只需一个参数，有变动，只需在方法内部改动，缺点就是调用者不知道要赋值对象的哪些值，被调用者舒服了，而调用者就崩溃了。
2是分散的参数 (name,description) 我个人倾向于这种，参数是明确的，这种才是好的

少玩精巧的对象交互，有时候觉得一个方法就可以搞定，结果却束缚在对象思维里，搞出了几个对象来完成这个功能很多面向对象的设计都迂回曲折，相对来说，反而是过程式代码更加容易理解。

仔细琢磨一下这个现象就知道，不是因为python真的比.NET简单，也不是因为python程序员水平高（实际上那边自以为是的菜鸟非常多），就在于他们社区的风格告诉大家“这个真的很容易”。

因为当框架的成本（包括心理成本）较低，推倒频繁时，很自然的就会注意什么不应该做入框架避免影响复用；同时，框架和框架调用的元素之间的接口也会被赋予更多的考虑，趋向于合理。我感觉你的意思就是最好能自己控制框架，而且这玩意要不复杂

“一个个人经验是，更加重视局部输入输出的明确简单，少玩精巧的对象交互，使组织部分成为一个灵活的粘合层。” 这个看的模糊，能说下这个不

我本来是想提Monorail来着 :) 不过毕竟没真正了解过，就算了。其实放到python那边，是个web开发者都会做个自己的框架瞎玩玩的，大多都是这种Web MVC、URL路由到方法这种。



另一方面，python作为一个动态语言，可能给人留下了“loli好身娇体柔易推倒”的印象（可惜只有大多数东西都“易推倒”这一点是真的），又总能找到合适的库或源代码，用来做框架正合适。



api，调用者知道自己需要传什么，被调用者也知道自己需要什么


为什么会出现这个问题，我认为是根本上误解了面向对象，对面向对象的胡乱使用。

需要说明的是，我并不是说那种迂回设计不够精巧，恰恰是这种精巧易于常人，绝对是天才的思维，问题是我们如何向更多凡人展现这种天才的思维？我认为面向对象是把问题变得易于理解为目的的。有人能够直接书写机器码，难道这不是非常了不起的技术么，但是这是难以被大众所理解的天赋。面向对象超越过程的，并不是更加“优秀”，而是更加大众。