p*****2
发帖数: 21240 | |
f*******t
发帖数: 7549 | |
t*****d
发帖数: 525 | 3 go 没太多 oo 思想，基本上就是一 C 语言的 2.0 版。。
【在 p*****2 的大作中提到】
: 思维跟Java还是非常接近的。
|
p*****2
发帖数: 21240 | 4
像C那么搞会很噁心。
【在 t*****d 的大作中提到】
: go 没太多 oo 思想，基本上就是一 C 语言的 2.0 版。。
|
d*******r
发帖数: 3299 | 5 同意, 不像 Java, 像 C
【在 t*****d 的大作中提到】
: go 没太多 oo 思想，基本上就是一 C 语言的 2.0 版。。
|
f******2
发帖数: 2455 | 6 go这东西真能成事吗？除了做api server什么的？
【在 d*******r 的大作中提到】
: 同意, 不像 Java, 像 C
|
p*****2
发帖数: 21240 | 7 go的封装性很差
想封装就得上method
【在 d*******r 的大作中提到】
: 同意, 不像 Java, 像 C
|
p*****2
发帖数: 21240 | 8 API server 本来就是一大块吧？
做一些tools也成
【在 f******2 的大作中提到】
: go这东西真能成事吗？除了做api server什么的？
|
p*****2
发帖数: 21240 | 9 大牛有什么像c的sample吗？
【在 d*******r 的大作中提到】
: 同意, 不像 Java, 像 C
|
d*******r
发帖数: 3299 | 10 我go还没入门, 肯定不如二爷你懂了.
为啥像C, 按照我的粗浅理解:
一直显示地check返回值, 不甩异常;
不照搬继承那一套, 用类似结构体+带类型的接口.
【在 p*****2 的大作中提到】
: 大牛有什么像c的sample吗？
|
|
|
d******e
发帖数: 2265 | 11 二爷没做过底层的系统软件吧。
我们当年就是if else goto 堆的
go 这个层面真的不用oo
【在 p*****2 的大作中提到】
: API server 本来就是一大块吧？
: 做一些tools也成
|
p*****2
发帖数: 21240 | 12
我做C n年了。我当然可以这么搞，但是这不是最好的方式。
我试过fp和pp，最后发现还是oo更适合。
【在 d******e 的大作中提到】
: 二爷没做过底层的系统软件吧。
: 我们当年就是if else goto 堆的
: go 这个层面真的不用oo
|
p*****2
发帖数: 21240 | 13
OO基本的用途是程序的组织，你说的这些是小地方。语言当然是像C，但是你程序写起
来要如何组织，就不一定要走C的struct和function了。当然你可以这么写，比如写成
f(s), 但是这么写一般都不如s.f()更方便。而且f的visibility是整个package，s.f()
的visibility就是s了。
写起来来会有各种各样问题，最后我发现这么写还算make sense。
struct 相当于 class
newStruct() 相当于 new Class()
method 就是 Java里的method
function 就是 Java里的static method
即使这样，attributes还是不能封装，如果真想封装可能就需要fp了。
这是封装，关于继承就是需要用embeded type了，当然多态就是interface了。 其实
java也讲究接口和组合。
所以这样看来，程序的组织和思路就跟java一致了。
如果按照fp的写法，go是很不方便的，只能放弃之。
按照pp的写法，go的很多feature没有用到，程序大起来C语言的缺点就全来了。而且C
的很多feature，go里面还是缺失的。
【在 d*******r 的大作中提到】
: 我go还没入门, 肯定不如二爷你懂了.
: 为啥像C, 按照我的粗浅理解:
: 一直显示地check返回值, 不甩异常;
: 不照搬继承那一套, 用类似结构体+带类型的接口.
|
d*******r
发帖数: 3299 | 14 你说这些，主要是封装和重用吧,
但是, 我觉得封装重用!=OO, 特别是 Java, C++ 这种经典的OO.
比如经典OO的继承和多态， 是个tree结构，其实有时不如graph灵活，
于是又搞 interface 这种来补充， 再搞依赖注入啊反射啊之类的.
在 C, Go 里， 重用点代码， 其实也不用都重用经典OO的那些概念.
类似的还有动态语言， 比如 JS, 封装和重用代码也不一定要上 class.
成
()
【在 p*****2 的大作中提到】
:
: OO基本的用途是程序的组织，你说的这些是小地方。语言当然是像C，但是你程序写起
: 来要如何组织，就不一定要走C的struct和function了。当然你可以这么写，比如写成
: f(s), 但是这么写一般都不如s.f()更方便。而且f的visibility是整个package，s.f()
: 的visibility就是s了。
: 写起来来会有各种各样问题，最后我发现这么写还算make sense。
: struct 相当于 class
: newStruct() 相当于 new Class()
: method 就是 Java里的method
: function 就是 Java里的static method
|
z****e
发帖数: 54598 | 15
oop跟pp最大的区别就是封装和重用代码
oop之所以被发明出来就是为了重用代码，要不然封装了干什么呢？
object/class本质上就是一种封装，跟struct是一样的
swift里面这两关键字几乎没有区别，除了default一些设置有所差异外
封装的目的也就是为了重用，否则没有必要封装
封装之后就是object，制造出这个概念的目的就是为了封装
否则不需要发明这个概念，而至于什么继承和多态
这个其实是副产品，因为有了封装，才有了继承和多态
如果连封装都没有，就谈不上继承和多态了，而不用继承和多态
只要有了封装，object就造出来了，至于叫不叫class，这个无所谓
不是只有class出现了才叫做oop
oop的思想就是无论什么时候都要求你封装你的代码
这个对于大项目来说是非常重要的，没有封装的代码，就像到处流窜的盲流
最后你自己都不知道到哪里去找他们
di和relfection并不是oop的产物，di因为需要有一个proxy
而oop到处都是object，所以有了宿主，比较容易搞
没有这个proxy，你想inject，怎么做？
relfection的话，不是oop一样可以做reflection
只不过reflect出来的东西都是object
因为都是名词，要不然怎么描述呢？
function如果不是object，那你拿到手上的是什么呢？
总需要描述才能做到，所以这两个在oop里面用得比较多，不是为了补充
是其他非纯粹oop的语言比如py,js这些根本做不到而已
实际上vert.x的讨论里面就有关于di的需求的讨论
最后其他语言开发者反对，反对的原因也很简单，因为做不到
不是不想做，是根本无能为力，没有proxy，怎么inject？
而做到了di的spring在decouping方面有天然的优势
你最后想写成一团都很难，代码就非常便于管理
不要把做不到说成不想做
【在 d*******r 的大作中提到】
: 你说这些，主要是封装和重用吧,
: 但是, 我觉得封装重用!=OO, 特别是 Java, C++ 这种经典的OO.
: 比如经典OO的继承和多态， 是个tree结构，其实有时不如graph灵活，
: 于是又搞 interface 这种来补充， 再搞依赖注入啊反射啊之类的.
: 在 C, Go 里， 重用点代码， 其实也不用都重用经典OO的那些概念.
: 类似的还有动态语言， 比如 JS, 封装和重用代码也不一定要上 class.
:
: 成
: ()
|
z****e
发帖数: 54598 | 16 举个di的例子
a,b,c三个class
a中用了b.func
b中用了c.func
c中用了a.func
这三个classes凑成一坨
里面任何一个class改动了，其他两个都需要跟着compile
随着这个互相引用的classes变多
最后随便一个小改动，都会导致整个项目重新compile
就很麻烦
如果有了di
这些class的改动和编译都是独立的，你改了一部分，重新编译这部分就好了
剩下你不用管，这就实现了比较高级的封装
连compile什么都是独立的，而要实现这个，你不得不找到一个proxy
否则根本无法di，我要inject进去一个func，那也得有个target才行
否则怎么inject？
这个功能不重要吗？我觉得相当重要
对于_大_项目来说
小项目随便搞，无所谓，但是_大_项目当然很重要
oop之所以被搞出来，捧到一个比较高的位置上去
很重要一个原因就是用来address大项目带来的各种问题
go发明出来，目的也是为了大项目，最后殊途同归也是意料之中的事 |
z****e
发帖数: 54598 | 17
继承！＝oop
封装才是oop的精髓
object这个概念就是关于封装的概念
concept of "objects", which are data structures/*所以struct也是object*/ that
contain data, in the form of fields, often known as attributes; and code,
in the form of procedures, often known as methods.
【在 d*******r 的大作中提到】
: 我go还没入门, 肯定不如二爷你懂了.
: 为啥像C, 按照我的粗浅理解:
: 一直显示地check返回值, 不甩异常;
: 不照搬继承那一套, 用类似结构体+带类型的接口.
|
z****e
发帖数: 54598 | 18
成
()
用swift来看这些关键字就很清晰了
func提到1st class citizen的位置
fp就基于此，那java中对应的只有static method
其实大同小异，区别仅仅在于java强制要求把static method封装起来
而swift等语言没这个要求，再次说明oop是关于封装的p，什么时候都在强调封装
struct和class在swift中就是一个东西
没有什么本质区别
【在 p*****2 的大作中提到】
:
: OO基本的用途是程序的组织，你说的这些是小地方。语言当然是像C，但是你程序写起
: 来要如何组织，就不一定要走C的struct和function了。当然你可以这么写，比如写成
: f(s), 但是这么写一般都不如s.f()更方便。而且f的visibility是整个package，s.f()
: 的visibility就是s了。
: 写起来来会有各种各样问题，最后我发现这么写还算make sense。
: struct 相当于 class
: newStruct() 相当于 new Class()
: method 就是 Java里的method
: function 就是 Java里的static method
|
d*******r
发帖数: 3299 | 19 我倒是觉得这里大家讨论的东西，没有本质矛盾，就是叫法，名字定义啥的，不一样. |
p*****2
发帖数: 21240 | 20 我觉得pp和oo还是有很大区别的
我尝试过用go写pp和fp都不好用
【在 d*******r 的大作中提到】
: 我倒是觉得这里大家讨论的东西，没有本质矛盾，就是叫法，名字定义啥的，不一样.
|
|
|
d*******r
发帖数: 3299 | 21 我懂你的意思，比如 f(s) VS s.f() 这个例子.
我只是不喜欢经典OO那一套东西，比如继承多态之类，不信你看看我上面的帖子.
最重要的还是封装和模块化，不一定要用经典OO的有些概念.
【在 p*****2 的大作中提到】
: 我觉得pp和oo还是有很大区别的
: 我尝试过用go写pp和fp都不好用
|
p*****2
发帖数: 21240 | 22
design pattern吗？应该不需要。go是支持fp的，没必要用那些生硬的模式。
封装很重要，go做的很不好。
继承缺失不用，需要的时候就是embeded type
多态就是interface了，haskell也是这么搞的
确实跟java不一样的是上来思维就是oo，而go是需要的地方上oo。如果真不需要，确实
不必强上。
【在 d*******r 的大作中提到】
: 我懂你的意思，比如 f(s) VS s.f() 这个例子.
: 我只是不喜欢经典OO那一套东西，比如继承多态之类，不信你看看我上面的帖子.
: 最重要的还是封装和模块化，不一定要用经典OO的有些概念.
|
d*******r
发帖数: 3299 | 23 我的意思是，只要可以自然地模块化封装重用代码，名字概念我不太care，当然我不如
你们严谨.
就好像有点fp功能，function是第一公民，很多经典的design pattern for OOP不用更
好.
【在 p*****2 的大作中提到】
:
: design pattern吗？应该不需要。go是支持fp的，没必要用那些生硬的模式。
: 封装很重要，go做的很不好。
: 继承缺失不用，需要的时候就是embeded type
: 多态就是interface了，haskell也是这么搞的
: 确实跟java不一样的是上来思维就是oo，而go是需要的地方上oo。如果真不需要，确实
: 不必强上。
|
p*****2
发帖数: 21240 | 24 同意 自然最重要
【在 d*******r 的大作中提到】
: 我的意思是，只要可以自然地模块化封装重用代码，名字概念我不太care，当然我不如
: 你们严谨.
: 就好像有点fp功能，function是第一公民，很多经典的design pattern for OOP不用更
: 好.
|
z****e
发帖数: 54598 | 25
封装是oop的精髓，所有的oop都强调封装
java甚至连static method都强行要求封装
这个对于1st class ctizien func来说是没有要求的
你不能把封装这个oop的精髓给拿走了，然后批判说，oop的继承是无用的
实际上继承和多态纯粹是副产品，oop自己都不用
java的verbose说的就是无时无刻都要求的封装，也就是各种包装
oop并没有无论什么时候都要求继承和多态，只有封装是无论什么时候都要求的
而这个恰恰是 大 项目很看重的一点，封装才是经典的oop思想
你不能为了批判而故意扭曲某些概念，pp和fp根本不强调封装
强调封装，模块化，恰恰就是oop的那条路
【在 d*******r 的大作中提到】
: 我懂你的意思，比如 f(s) VS s.f() 这个例子.
: 我只是不喜欢经典OO那一套东西，比如继承多态之类，不信你看看我上面的帖子.
: 最重要的还是封装和模块化，不一定要用经典OO的有些概念.
|
z****e
发帖数: 54598 | 26
func是1st class citizen就没有封装
随便写，oop要求放入一个object中去
design pattern是每一个p都有的东西
用不用，纯粹根据环境决定
你需要明白为什么用，然后再决定要不要用
而不是看不懂说这个东西没有用，我觉得很多人根本是没有看懂patterns，然后说没用
design pattern一直都不是一个强制的要求
而是optional，实际上一直都有反pattern的说法
就是对于套路，可以不用，没有人强制要求说一定要用这些patterns
而用了这些patterns，恰恰是民工们自己觉悟出来，哦应该要这么用
有如下好处,blablabla，实际上随着fp的介入，dp用得越来越多
比如subscribe/publish pattern，就在streaming中得到了应用
就比如factory，在spring出现之前，factory是一个比较好的把compile部分剥离的办法
有了factory pattern，你如果修改了product的impl，就不需要我用factory的objects
跟着compile，这样就实现了更大程度的封装和decoupling，所以说来说去都在说封装
而封装恰恰是oop的精髓，整个oop的概念就从封装而来，可以说只要你强调封装
这就是经典oop，你不能把最重要的部分从这个概念中抽出来，然后说，这个东西没用
离开了封装，那还叫oop么？没了继承，没了多态，oop还是oop，因为万事万物都是
object
这个并没有要求一定要继承，一定要多态 etc.
实际上你工作中用java，如果有人要求你一定要用继承，一定要用多态
你马上就会怀疑这小子脑子进水了吧？
只是你有了object之后，可以让这个object衍生出去，虽然一般你懒得这么搞
design pattern也是一样的，写代码时候没有强制要求一定要用某些patterns
oop最重要的就是封装，你写java，随时都在封装你的代码
而这个封装就是object，而这个恰恰是pp和fp所不强调的
fp的func很自由，没有属主，pp就更原始了
pp和fp都比oop要古老，这些p在oop诞生之前，并没有很好滴address大项目带来的问题
恰恰是oop诞生的一个主要原因，oop最简单，也最强调封装，什么都要封装
所以写hello world的时候，oop最麻烦，但是大项目上，oop就变得很清晰了
只要你的项目越来越大，你一定会朝着oop这条老路上走过去
【在 d*******r 的大作中提到】
: 我的意思是，只要可以自然地模块化封装重用代码，名字概念我不太care，当然我不如
: 你们严谨.
: 就好像有点fp功能，function是第一公民，很多经典的design pattern for OOP不用更
: 好.
|
a******e
发帖数: 82 | 27 go的强大之处在于multithread
【在 p*****2 的大作中提到】
: 思维跟Java还是非常接近的。
|
p*****2
发帖数: 21240 | 28 concurrency 吧？
【在 a******e 的大作中提到】
: go的强大之处在于multithread
|
f******2
发帖数: 2455 | 29 我的体会：如果不考虑conurrency，go基本就是分分种被python干掉的命。python的那
些twist什么的让人看着蛋疼，才给了go冒头的机会。
请各位大牛指正
【在 p*****2 的大作中提到】
: concurrency 吧？
|
p*****2
发帖数: 21240 | 30
还有一个就是performance，go比script强很多。
go就是靠那么几个亮点火起来的。语言设计很烂，不过底层做的是很牛逼。
【在 f******2 的大作中提到】
: 我的体会：如果不考虑conurrency，go基本就是分分种被python干掉的命。python的那
: 些twist什么的让人看着蛋疼，才给了go冒头的机会。
: 请各位大牛指正
|
|
|
d******e
发帖数: 2265 | 31 python就是性能不行。 无他。
【在 f******2 的大作中提到】
: 我的体会：如果不考虑conurrency，go基本就是分分种被python干掉的命。python的那
: 些twist什么的让人看着蛋疼，才给了go冒头的机会。
: 请各位大牛指正
|
D*******a
发帖数: 3688 | 32 Go没有继承和多态，怎么玩OO？
【在 p*****2 的大作中提到】
: 思维跟Java还是非常接近的。
|
z****e
发帖数: 54598 | 33 oop现在谁用多态？
还有继承，如果不算interface的话
extends几乎没人用了
spring一推广，除了游戏比如android还在用这些以外
一般server side java用得越来越少，几乎都是interface+impl搞掂
【在 D*******a 的大作中提到】
: Go没有继承和多态，怎么玩OO？
|
p*****2
发帖数: 21240 | 34 embeded type
interface
【在 D*******a 的大作中提到】
: Go没有继承和多态，怎么玩OO？
|
d*******r
发帖数: 3299 | 35 我还是那个观点，自然地封装和模块化最高，
当然OOP这方面做得是不错，不过，具体用什么概念，其实不用太死板，
封装和模块化其实是一切高质量编程的基础.
OOP是基于名词的封装和模块化；FP是基于动词的封装和模块化。
封装好了，都是好代码，好代码就是人类读起来改起来自然方便的代码.
【在 z****e 的大作中提到】
: oop现在谁用多态？
: 还有继承，如果不算interface的话
: extends几乎没人用了
: spring一推广，除了游戏比如android还在用这些以外
: 一般server side java用得越来越少，几乎都是interface+impl搞掂
|
p*****2
发帖数: 21240 | 36
是。只是go如果按照fp那么写会很恶心的。
【在 d*******r 的大作中提到】
: 我还是那个观点，自然地封装和模块化最高，
: 当然OOP这方面做得是不错，不过，具体用什么概念，其实不用太死板，
: 封装和模块化其实是一切高质量编程的基础.
: OOP是基于名词的封装和模块化；FP是基于动词的封装和模块化。
: 封装好了，都是好代码，好代码就是人类读起来改起来自然方便的代码.
|
c****f
发帖数: 1102 | 37 golang这种就叫duck type而已根本不是OO, 没有类这个概念
无非是你喜欢怎么写 自己怎么使用函数 很多底层的应用根本不需要 特别是系统层面
type X stcurt{
}
func (x *X) SayHello() {
}
x.SayHello()
然后某位提到的多(对象)单个call可以用interface{}来实现
看看很多linux的c代码 基本不需要oo和method概念在里面 比如 nginx
golang好处是 对系统工程师来说 设计程序可以不用去写C C才叫一个恶心 看看nginx
代码 简直要吐好嘛 |
p*****2
发帖数: 21240 | 38
nginx
OO跟有没有类到没有直接的关系，其实。
【在 c****f 的大作中提到】
: golang这种就叫duck type而已根本不是OO, 没有类这个概念
: 无非是你喜欢怎么写 自己怎么使用函数 很多底层的应用根本不需要 特别是系统层面
: type X stcurt{
: }
: func (x *X) SayHello() {
: }
: x.SayHello()
: 然后某位提到的多(对象)单个call可以用interface{}来实现
: 看看很多linux的c代码 基本不需要oo和method概念在里面 比如 nginx
: golang好处是 对系统工程师来说 设计程序可以不用去写C C才叫一个恶心 看看nginx
|
