go说话php教程技巧_若何运用Golang进行无心智包袱的编程

文章目录 [+]

不知读者是否也会时候想: 我该怎么写这段代码才优雅, 后期改起来方便?

努力思考却还是得不到最佳答案, 烦躁等负面感情不约而来。
这便是在编程过程中的心智包袱。

go说话php教程技巧_若何运用Golang进行无心智包袱的编程

这篇文章将从多个方面来简化思考, 希望它能给努力思考的你带来一点小灵感.

（图片来自网络侵删）

题外话: Golang哲学便是\公众少便是多\"大众, 志在减少开拓者的心智包袱. 不过再好的措辞也敌不过\"大众人\"大众, 请接管Golang的风格否则写出PHPGo, JavaGo真是作茧自缚。

关于设计模式

java的23种设计模式? 再见.

不是说他们没有浸染，只是说它们太去世板繁芜，学习它们常日入不敷出。

对付编程还有很多须要把稳的地方（下文），而不要只局限于设计模式。

我给出的建议是只须要理解一个大概，在平时编程中能用则用。

关于面向工具

Golang比较Java来说, 对\公众面向工具\"大众这件事的支持是\"大众不完全\"大众的.

但话又说回来现在的\"大众面向工具编程\公众逐渐被扭曲为了\"大众面向类编程\"大众（COP），而COP是繁芜并难以理解的，COP有好处但要发挥出来并不随意马虎。
以是Golang决定抛弃所有不必要的观点以改进这个问题。

现在不必再理解封装(这个大略到不须要理解), 多态, 继续.

在golang中只须要理解两个更实在的东西: 接口, 组合.

接口

Java 之父 James Gosling 在某次会议上有过这样一次问答：

I once attended a Java user group meeting where James Gosling (Java’s inventor) was the featured speaker.

During the memorable Q&A session, someone asked him: “If you could do Java over again, what would you change?”

“I’d leave out classes,” he replied. After the laughter died down, he explained that the real problem wasn’t classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

大意是：

问：如果你重新做 Java，有什么是你想改变的？

答：我会把类（class）丧失落。
真正的问题不在于类本身，而在于基于实现的继续（the extends relationship）。
基于接口的继续（the implements relationship）是更好的选择，你该当在任何可能的时候避免利用实现继续。

---- 摘自 Golang OOP、继续、组合、接口 https://studygolang.com/articles/20972

在Golang中只须要记得一个东西: Interface(接口).

拜会io.Reader接口就知道这种设计有多厉害.

读文件是它, 读网络要求也是它, 更骚的是对付linux(Every thing is a file)来说用它就能操作近乎全体系统了.

大略的说: 当某个功能(如去北京)有多种(或者往后可能有多种)实现办法(如坐火车/飞机/骑车)的时候, 用接口.

组合

组合理解起来并不繁芜, 不过是一个语法糖, 就算没有组合功能也绝不影响Go程序的运行.

如下代码, 没有组合换一种写法即可.

// 组合type L struct { sync.Mutex}// 这样利用L.Lock()// 没有组合type L struct{ l sync.Locker}// 这样利用L.l.Lock()

大略的说: 组合能用则用，如果你不知道如何利用或者不用也并无大碍。

关于可掩护性

\"大众开闭原则\公众对我启示很大.

原文是这样:

伯特兰·迈耶一样平常被认为是最早提出开闭原则这一术语的人，在他1988年发行的《面向工具软件布局》中给出。
这一想法认为一旦完成，一个类的实现只该当因缺点而修正，新的或者改变的特性该当通过新建不同的类实现。
新建的类可以通过继续的办法来重用原类的代码。
衍生的子类可以或不可以拥有和原类相同的接口。

但实在我们在开拓的时候并不是一贯都在和工具打交道.

在我看来, \"大众开闭原则\"大众适用于平时写的任何代码.

完全理解\公众开闭原则\"大众可能还是会造成心智包袱, 以是先打住, 只须要这样:

一个函数只做一个功能(事情), 一旦这个功能开拓完成, 这个函数应该\"大众闭合\"大众, 不应该再修正(bug除外).当须要修正功能, 应该只管即便将修正也写成一个函数，尽早的进入分支判断去调用新修正，而原代码不变。

这便是 \"大众对修正闭合, 对扩展开放\公众.

这里不得不在提及\"大众面向函数编程\"大众, 它的思想包括但不限于:

一个函数只做一个功能函数无副浸染

它恰好利于修正, 利于写出符合\公众开闭原则\"大众的代码.

关于缺点处理

默认的errors包在对付多层的繁芜运用是不足的，这种情形下建议自行封装，但别太追求完美在项目中够用就好。
我们等待官方方案即可: https://github.com/golang/go/issues/29934

关于命名

restful能办理大部分命名问题.