说到宿命,不得不提到的第一个故事就是经典的希腊神话《俄狄浦斯》。俄狄浦斯在不知情的情况下，杀死了自己的父亲并娶了自己的母亲，表达了一种命运的无常和无奈。在村上春树《海边的卡夫卡》中。主人公一开始就尝试摆脱自己弑父辱母的预言诅咒。这里就借鉴了俄狄浦斯的典故。
这种预言诅咒的套路在影视剧中很常见。类似于主人公一开始就被下了不止一个预言。然后主人公不以为然，但是接下来发生的事件让他越来越相信自己预言是真的，接下来主人公开始恐惧和挣扎，并作出各种事情来摆脱自己的宿命。举个例子，在权力的游戏中。瑟曦皇后在很小的时候，就被女巫说了三个预言：
一句话来说就是为了兼容。
早期的计算机，使用的是分段管理，比如16位的8086机器，最大的内存地址到,但是使用段寄存器+偏移量的方式，可以访问到1MB的内存。（把1M内存分为16个段)。例如8086四个段寄存器（代码段寄存器，数据段寄存器，堆栈段寄存器，附加段寄存器）。并且分段还有一个好处是做到数据隔离，保证安全。
后来32的80386采用了分页内存管理，使用虚拟内存地址映射到物理内存，所以让每个进程看上去自己都有4GB的内存空间（虚拟内存地址）可用。每一个页大概有4K，而且真正被使用的时候才会分配真实的内存，否则可能在硬盘上，或者就没有被分配。但后来的80386还保留了分段模式主要是为了兼容。
再后来使用了“段页式管理”，结合了分段和分页两种内存管理思路，用户程序的逻辑地址空间首先被划分成若干的逻辑段，每个段都有自己的段号(常量段，堆栈段)，然后再将这些段分页。所以不要把最早的内存分段管理和如今的段页式管理搞混，即使他们都有所谓的“堆栈段”，要分清它们的区别和联系。
总结一下分段内存管理的优势在于内存共享和安全控制，而分页内存管理的优势在于提高内利用率。
去年tb组内人玩了一次攀岩，我当时发挥的不错，爬上了一个难度很大的墙壁，貌似组里只有我一个人爬上去了。之所以能爬这么好，是因为我发现了玩攀岩有两个要领，第一，发力点是腿，你不要指望自己臂力大把自己拉上去，所以基本的动作都是，抓住墙壁，然后用腿用力一登。第二，我想到那些歪歪扭扭的岩壁，设计出来就不是让你舒服抓的，只要你沉住气，你会发现虽然马上就要掉下去了，但假如你能克服住心里的恐惧，还是能保持某种平衡和稳定的，或者说那种感觉根本不能算抓，只能说扒在上面。
不过后来我自己私下又去攀岩了几次，才发现我那次爬上去完全是作弊，因为那种3m左右的攀岩板子，上面是有数字标号的，你必须按照相同的数字向上攀岩才算数，因为大家都是第一次攀岩，不懂这些规矩，所以才导致我能蒙混过关的。其实我之所以会这么想，因为我始终是一个有点悲观的人，每次成功我都会想到可能是某个什么外因，或者运气好，让我侥幸成功。
但是后来我还是忍不住思考自己为啥能比别的小伙伴爬的好，我想到小的时候爬树爬墙是我最喜欢干的事情，我从小就是那种喜欢做点另类的不一样的事情的孩子，当别的同学都在跳绳，踢毽子，踢足球的时候，唯独我喜欢拿着铁环的那根杆和兵乓球在操场上一个人打“高尔夫”。不过更真实的情况是因为当时我家就在学校的后面，但是如果走正门就要绕个大远，所以我常常选择翻墙上学，其实我还引领过爬树翻墙的风潮，吸引到很多男生都跟着我一起去爬树，为这事学校还批评通报过一次。我从小就是个比较淘气比较疯的孩子吧。
这篇博客来源于我在组内的一次分享，我做了一些删减，并添加了其它一些元素，让它看上去更像是一篇博客。
这里我并不打算把23种设计模式从前到后的细讲一遍，而是提供一种想法，一种思路，算是我自己对设计模式的理解。真的想理解好设计模式，还是应该看《GOF》
所以首先我会抛出一些我的结论并尝试逐一的解释它们。
那本被称为《GOF》的设计模式书，出版于1995年，而且书中大部分例子都围绕着桌面GUI开发，因为那是当年最火的模式，那我的理解，其实对于我一个做java后端开发的人来说，它其实有点过时了，比如里面类似“备忘录模式”，“命令模式”，“组合模式”这种，我可能一辈子都不会用到。再比如像是“迭代器模式”，“装饰器模式”这种，其实如今的语言已经默认都支持了。还有类似ioc控制反转这种，其实本身也可以算一种设计模式，但是因为理论和时间成熟相对较晚，并没有包含在GoF中，
所以也没必要在语言中，特别的去实现这一种模式了。总的来说，我想表达的一种思想就是：“只学习属于自己领域的那部分设计模式，其它的大概了解就行。”
你应该知道在学习设计模式的时候，有些类似《head first》，《大话设计模式》，这样的书籍，这些书籍看上去很好读，读起来很轻松很有趣，但是暴露一个严重的问题是，你只能大概听懂和了解这个模式是用来干嘛的，但是实际上你根本不知道怎么把它实践到具体的例子中。说简单点，根本没有什么地方，能让你写类似“飞机，大炮，坦克”的例子，你需要自己建立抽象思维来根据具体的场景，抽象出模型来。所以还是看原版的《GOF》好点，这本书首先会给你讲，到底我们在面临一个什么具体的case，然后针对这个case的设计模式是什么，在解决什么核心诉求，本质上来说，解决问题的场景，是设计模式的关键，如果你沉迷于背设计模式，背类图，那你会发现，很多设计模式的类图都差不多。
这个可以说是源于封装思想的基础，明确好每个类的职责，划分好边界。面向对象编程本身来说，就是一些对象的相互交互，本身就是对象与对象之间相互发送消息。所以设计一个对象，你要提供接口，限制类的访问权限，定义好类的协议。所以首先要符合最基本的建模思想，接下来再谈设计模式。
简单的来说，就是面向接口编程，而不是面向实现编程，因为面向了接口编程，你可以让实现随意的被替换，这极大了增加的系统灵活性。不仅仅局限于对某个算法的实现细节下沉。还包括像创建者类的模式那样，把对象的创建，下沉到实现类中去。总之，设计模式总是看上去利用接口来做一个中间对象，从而实现了一个“缓冲区”，让你可以通过这个“缓冲区”间接地做很多事情。
一个好的文章，在开头的部分，就能吸引住读者，继续读下去，为此我大费周折思考如何给这篇博客写一个好开头，但是我想了半天也没想出来，而且到目前为止，你看到我写的都是些废话，但你先别急着走，在这篇博客里是没有“你为什么要从现在开始写博客”这样没用的鸡汤型劝说，也不会有任何看似煽情，但是没有一点卵用的矫情句子，而是关于写博客的，总结性的经验技巧。毕竟自己已经写了快两百多篇博客了，技巧方法还是能总结出来一些的，所以接下来我就认真的和你聊聊“写博客这件小事”吧。
你不能把你放到网上的学习笔记称为博客，即使你在学习笔记的周围添加了一些承上启下的客套话。像是“好，下面让我来一起学习python吧。”郭德纲说过一句话，“说相声是什么？就是聊天，看两个人聊天，才叫相声”。同理我私以为，如果你在读一篇文章的时候，感觉就像有一个人坐在你对面，给你朗朗上口的讲一个故事，或者讲一个技术点，或者科普一个知识，那才叫博客。大段的摘抄，总结书的笔记，都不能称之为博客。因为博客不仅仅是写给自己看的，也是写给别人看的。
我在这里指的故事，是指发行于报纸，杂志，哪怕是公众号这种，纯粹以读者为中心的文章，因为作为一个博客，其本身是自己运营的一种爱好产物，并不完全服务于大众读者，因为读者既没有给你发工资，也没有点击你投放的广告，写博客本身带有自我提升的属性，而不仅仅是为了分享传播，说白了就是不仅为了他人，还为了自己。
看看那些《让优秀成为一种习惯》，《不完美才完美》，《如何成为一个精致的女人》，这种你还没点开就已经知道里面写的什么的文章，你最好别写，或者最多写一次，我见过有一个人的博客，十几篇博客，其实在翻来覆去的说鸡汤，感觉整个人都陷入到死循环了。文章要写的头头是道，脚踏实地，而不是虚无缥缈的，自己都不相信的大道理。
本故事纯属虚构，如有雷同，纯属巧合
某天，我刚午睡醒来，准备给自己做一杯手冲咖啡，拿着手冲壶走向饮水机的时候，无意中看到两个开发对着屏幕在那里指指点点的，仿佛在说着什么，只见一个说的头头是道，一个听得津津有味，我当时觉得他们肯定在谈论什么有意思的事情，所以凑过去打算听听，结果他们谈论的事情令我醍醐灌顶，可以说让我对编程有了新的思路，所以这里我尝试将他们的对话总结出来，分享给你们。
哦对了，他俩的名字我不能告诉你们，本来我想用鲍勃(Bob)和爱丽丝(Alice)来代指他俩的，但是又觉得这个梗早已经被编程界给玩烂了。所以我打算给他俩起名叫Foo和Bar。
Bar：“其实我一直想尝试让自己的代码变得灵活起来，比如把写死的东西给改成配置，但是我并不能满足于此，因为我总觉得自己代码还不够灵活，你能在给我一些思路么？”
Foo：“哈，说道思路，我确实可以给你提供一些，不过我尽量不会给你讲一些具体的例子，因为授人与鱼不如授人于渔，所以我会给你提供一些编程思想上的东西，帮你开阔视野。”
Bar：“好的，我洗耳恭听。”
Foo：“首先我们先来思考下，什么是所谓的灵活性。不说那些课本上比较官方的词汇，你所理解的代码灵活是什么样的？”
Bar：“最起码不用我每次有个什么新需求，都要让我改来改去的上线。”
Foo：“但是有的需求你是不得不上线。”
Bar：“对，这我知道，但是对于有些需求，其实是有些重复的东西，提取出来，然后在调整的时候，修改下配置就行了。”
Foo：“恩，很好，你提到你可以把某些共性的东西，提取出来，所以我们先来看你在初学代码时候的第一个例子。让你从1打印到10，你最开始会写出这样的代码.”