Java & Go 设计模式实现

设计模式这玩意，该用的地方自然就会用，不该用的时候别嗯套。
当你写代码思考‘这里该用什么设计模式’的时候，就是不该用。

@Livid
12 、13 楼，编程语言引战、人身攻击。
op 也是好心分享，看到肯定很心寒。没想到用个编程语言也要搞个三六九等的优越感来攻击别人。

@uds9u32br 赞同观点

@mmdsun 哈哈哈 问题不大

语言是在特定的历史背景下解决了某些特定的问题，现代语言肯定是借鉴了之前的一些思想和缺点创造更好的语言。
我觉得语言并没有优劣之分。能捉到老鼠的都是好猫

不如分享下怎么用 AI

除了几个结构型模式，其他模式都是语言自身实现不了形成的，比如 java 一个 clone 就实现了原型，就不怎么谈这个设计模式，最终都会变成内在语法，不如多看看其他比较现代化的语言。

@Ketteiron 单例的重点不止是单，它得先是例。
工厂什么的都挺常用的，只要你不能即地初始化一个东西，那个帮助你初始化的设施都可以叫工厂。

@mmdsun 如果真是人身攻击的话没这么好听，还有别诬陷我，我没说编程语言有三六九等，道德侠玻璃心，一点屁事就 @站长

@iseki #27 这个单例或许加个引号更合适，确实不是"例"，一时也想不出更贴切的名词，本质上都是全局变量的唯一访问点。部分语言提出单例概念是因为变量必须放在 class 内，因此催生了一个绕过方法。假如语言支持在 class 外也有作用域，那么全局变量的载体不一定要是对象，js 可以是 module ，go 可以是 package ，也没必要实例化了，它们是语言级别的特殊对象，也能实现对象的特性(一次初始化、修饰符、延迟加载)，而二者的具体差异可以忽略不计(例如静态内存 vs 动态内存)。
写 Java 的也从来不会用单例，用的是依赖注入默认情况下表现出来的单例特性，这其实也不是单例。

@darksword21
如果没记错，前几天你在另一个帖子也发过“Java 造成永久性脑损伤”的言论。

可能 Go 用久了会变成谷歌的安卓嘴，语法复读症越来越重。😂
error handling 造成的语法性心理创伤，也不比 Java 好到哪去——应该 Go 损伤的，是灵魂吧。

@mmdsun 哈哈哈哈

@Ketteiron 你误会了，Java 也有 static 关键字。“例”是为了可以被引用，可以等同于一般的 Object （ Java 语境）

@mmdsun 理中客装不下去了自己开始人身攻击了，笑死

@darksword21 你不能只在别人攻击你的时候才说这是人身攻击

@mgaic 我只是想用他自己的话说他，如果他认为我是在人身攻击那么他现在自己也装不下去了开始人身攻击

但是我一开始的评论没有人身攻击的意图（自认为，如果你说有那么你说的对但我不接受）

@mmdsun #22 他俩只是在调侃，你别太当真了。

我写了 5 年的 Java ，刚转 Go 的时候，大脑也受损了，还是 Java Spring 的那套思想。需求一下来，我就想建立多层次的数据模型，然后用接口来定义能力，用抽象类来区分子类的功能，然后再把能力组合起来，用各种设计模式......

这样一个需求可能要创建很多个类，典型的 “面向对象 + 接口 + 抽象类 + 设计模式“ 的 Java 编程思路，大约写了 8 个月的 Go ，才丢掉这套思想。

@iseki #32 确实如此，虽然多范式语言并不关心这点。singleton (单例) 与 monostate (单态) 都是编程语言在不支持顶层作用域函数/变量的情况下管理全局函数/变量的方案，缺点都差不多，相比之下单态更加差劲。
https://wiki.c2.com/?MonostatePattern
以 kt 举例，顶层 object 基本都被用成了 namespace ，我很少见到把它当单例用的。

@Ketteiron 那你 Kotlin 可能还是写少了（笑），你看 x 库和标准库中都有很多利用 object 的可被引用的特性的地方。
他们不是单例就不行吗？当然不是，你大可把全部成员变量都写到顶层 private var 上去，但是你没法让一个 .kt 文件 implements 某个 interface 。Kotlin 选择了 companion 而没有直接像 Java 一样暴露所谓的 static member 正是表达了在这一点上的取向。

Java 罪大恶极

@iseki #38 A 持有 B 的引用且能修改，是 OOP 的罪恶根源，标准库基本都是无状态/不可变对象(除了和 java 互操作的可变对象)，但最下游的消费者还是应该尽量多用函数式。
对一些全局变量，我的通常做法是设为私有顶级成员，相比 companion object 少写 3 行。(FP 致力于消除一切全局可变变量，理论上都是"错误"用法)。
interface implements extends 是类型约束的一部分，kotlin 作为多范式语言提供了更多的可选组合，例如用 object 委托实现适配一些接口，或者用函数类型+高阶函数进行限定(实现接口本质是提供一个符合签名的函数)。多范式语言提倡组合优于继承(委托、扩展函数)，函数一等公民(顶层函数、高阶函数、闭包)，使用语言提供的单元(module/package/.kt)而非 interface/class/object 组织代码就变成很自然的事，真要用接口也尽量用 SAM 。
写 kt 我一般还是建议不要太沉迷 OOP 的特性，多提升 FP 含量，少点过度抽象少写点代码。
https://www.reddit.com/r/Kotlin/comments/kziv7e/a_closure_is_a_poor_mans_object/