@liuhan907
@BigDogWang

所以说到底, 你俩的观点就是: "因为 Java 的语法就是这样的, 所以这样做是对的".
类似的观点有: "你生在这个国家, 那你就必须爱这个国家, 你说的问题都是国情决定的, 你说国外没用."

楼主问的语言确实是 Java, 但是这是一个通用的编程语言设计问题, 他的问题也可以解读成"Java 为什么要这样做? 是不是合理 ? 有没有更好的设计 ?"

我来说说我真正反感的地方:

我记得早期写 Java/C# 的时候, 把字段设置成 private 只是一个推荐做法.
如果你明确知道自己的字段直接访问没问题(比如只是当作数据载体用), 那么你应该允许我这么做. 哪怕将来确实有较小的概率需要加上访问控制, 也不过是一个简单的重构.

到了 2022 年, 当你在 IDE 里写 C# 或者 Java, 如果 class 的字段没有封装起来, IDE 会拼命的提示你, 这样做不行. 在 V2EX 这样的编程论坛里, 加上 getter/setter 被认为是天经地义的, 质疑的声音会被嘲笑. 这像极了疫情三年来出生的小孩, 他们以为人类出门就是必须带口罩的.

重申一下我的观点:

- 从语言设计层面, 这个问题有更优雅的解决方案.
- 即使是限定在 Java 现有的语法里, 要求所有字段都封装起来, 是矫枉过正, 得不偿失的.

@yaphets666 我只是提供一个判断问题的角度, 当然不是说适合每个人.

@BigDogWang 那么请说说你的理解.

@karloku 并不会, 如上.

@BigDogWang

"我就想问你。一开始你觉得不需要访问控制，然后到处直接访问变量。突然有一天，这个属性需要访问控制了，你改起来蛋疼不。。。不同语言本身就有不同的设计和风格"

不蛋疼, 如下:

```
# V1: no access control
class Person:
def __init__(self, name):
self.name = name

# V2: make name readonly
class Person:
def __init__(self, name):
self._name = name

@property
def name(self):
return self._name

@name.setter
def name(self, value):
raise AttributeError("name is readonly")


# no change to interface & usage:
p = Person("Foo Bar")
print(p.name)
# work with V1, Exception for V2:
p.name = "John Smith"

```

#82: "getter 和 setter 作用都不理解的（这不是 Java 特有的），我只能说在红利期程序员这碗饭太好吃了，不过看互联网公司这裁员势头，红利期也差不多过了，你不被优化谁被优化"

我要特别的替楼主怼一下#82 楼这个回答. 请你不要被他唬住.
有没有可能, 说这类话的人, 不过是因为他们没有经过自己的思考而人云亦云? 会不会是因为他先学了 Java, 甚至只学了 Java, 从而先入为主, 被禁锢在自己的思维茧房里了 ? 能问出最傻最基础问题的人, 会不会才是那个直面本质, 大胆思考, 甚至推倒重来, 开宗立派的人呢 ?

这个问题很有代表性.

我刚学编程的时候也疑惑过这个问题(C#/C++). 同样的, 人们给出的也都是封装, 重构, 访问控制之类的理由. 我将信将疑. 但因为当时的我所知甚少, 就姑且信之, 当作是 Good Practice.

直到后来我转向了 Python. 什么狗屁 getter/setter ? 它连 public/ptotected/private 关键字都没有, 默认字段都是 public 的(尽管你可以用比如 __name 来实现 private, 如果你真的需要).

Python 也可以用 @property / @property.setter 来实现一样的访问控制, 但同样, 仅仅是在你*确实*需要的时候.

别看这只是一个小小的语法偏好差异, 但它却启发了我对思维方式的反思:

- 加上 getter/setter 在某些特定情况下能带来一些好处, 那我们强制要求所有的字段都设成 private, 全部加上 getter/setter, 好不好啊 ?

- 面向对象有很多好处, 那我们强制要求万物皆对象, 哪怕是 Hello World, 都要定义在一个 Class 里, 好不好啊 ?

- 设计模式如此精妙, 能解决很多很多常见问题, 那我们把能套上设计模式的地方全部都用上, 要求每个程序员都掌握, 好不好啊 ?

- 既然戴口罩有利于预防流感, 那我们要求所有人都必须戴口罩, 不戴的不让上路, 好不好啊 ?

诸如此类.

我知道很多人会说好, 因为现实生活中有很大一部分人就是习惯别人给自己制定一个一劳永逸一刀切的规范, 然后他无脑跟着执行就行了, so easy.
但也有另一类人, 不喜欢被束缚, 不喜欢被别人的规范所限制, 喜欢自由自在的感觉, 哪怕这个确实会带来一些弊端和损失.

编程语言的选择, 以及是否移民的选择, 也可以借助这个问题一并回答:

如果你是前者, 那么你适合学 Java, 以及生活在国内.
如果你是后者, 那么你适合学 Python, 以及生活在国外.

最简单的难道不是 requirements.txt + pip freeze ? 用 dockerfile 做成镜像更佳.

光看照片, 我对这两个颜色都可以接受,没有特别的偏爱.

我买了银色, 因为据说不掉色. 到货后, 看起来普普通通, 虽然我也不介意.
后来公司又给我买了台灰色, 开箱的时候, 居然有了惊艳的感觉.

在 v2 问这个问题，就类似于你去知乎问：500 万在中国够不够生活？

方法 1: 参数结构不要嵌套, 然后 url 参数是可以重复的,比如 /search?city=广州&city=深圳. 当然后端需要正确的解析.
方法 2: GET 可以带 body, 相应的, 只要你的后端去读取 body 并解析就行了.
方法 3: 用 POST, 代码的首要意义在于实现功能, 不必拘泥于繁文缛节.

好像在我的群晖 NAS 上不工作, 提了一个 issue: https://github.com/trzsz/trzsz-go/issues/5
有人遇到同样的问题吗?

赞,我经常需要电脑上下载了视频拖到 NAS 上,有了这个要方便很多.

@AyaseEri 知乎既视感：“1000 万在中国大城市都不够买一套房，你确定够用?”

烦儿晒

内存肯定得上 32G ，要不然买什么 Pro ，直接 m1 Air 。

尺寸的话，你这样想：

如果是以往那种轻薄的设计，作为生产力工具，那无脑上 16.
然而，这一代 MBP 其实重量和厚度都超标了。
为了平衡这个缺陷，应该选 14.

当然如果你高大威猛孔武有力举重若轻，请上 16.

也许只是因为那个日子快到了？

有些显示器可以充当 hub 接外设，只要一根 type c 线连接电脑，充电，显示，扩展，全搞定