小编Jan*_*nar的帖子

我们开发人员编写的大多数应用程序都需要在启动时进行外部参数化.我们传递文件路径,管道名称,TCP/IP地址等.到目前为止,我一直在使用命令行将这些传递给正在启动的应用程序.我不得不解析命令行main并将参数指向他们需要的地方,这当然是一个很好的设计,但很难维护大量的参数.最近我决定使用环境变量机制.它们是全局的,可以从任何地方访问,从架构的角度来看不太优雅,但限制了代码量.

这些是我对这两种策略的第一次(也可能是很浅的)印象,但我想听听更多有经验的开发人员的意见 - 使用环境变量和命令行参数将参数传递给进程的起伏是什么？我想考虑以下事项:

1. 设计质量(灵活性/可维护性),
2. 记忆限制,
3. 解决方案可移植性

备注:

广告.这是我感兴趣的主要方面.

广告.这有点务实.据我所知,这是目前在Windows上一定的局限性巨大(超过32kB的两个命令行和环境块).我想这不是问题,因为如果需要,你应该使用一个文件来传递大量的参数.

广告.我几乎不知道Unix,所以我不确定这两种策略是否像在Windows上一样可用.如果你愿意,请详细说明.

正如Python 2 文档所述__repr__：

如果可能的话，这个（即__repr__）应该看起来像一个有效的Python表达式，可以用来重新创建具有相同值的对象（给定适当的环境）。

那么为什么类的内置函数__repr__不按照该准则行事呢？

例子

>>> class A(object):
...   pass
>>> repr(A)
"<class 'A'>"

为了满足准则，默认__repr__应返回"A"，即通常为A.__name__。为什么它的行为不同？我相信，这将非常容易实施。

编辑：“复制”的范围

我可以在答案中看到，讨论中并不清楚repr应该返回什么。在我看来，该repr函数应该返回一个允许您重现该对象的字符串：

1. 在任意上下文中并且
2. 自动（即非手动）。

广告1。看一下内置的类案例（取自这个SO问题）：

>>> from datetime import date
>>>
>>> repr(date.today())        # calls date.today().__repr__()
'datetime.date(2009, 1, 16)'

显然，假设的上下文就像您使用 import 的基本形式，即import datetime，因为如果您尝试eval(repr(date.today()))，datetime将不会被识别。所以重点是__repr__不需要从头开始表示对象。如果它在社区同意的上下文中是明确的就足够了，例如使用直接模块的类型和函数。听起来很合理，对吧？

广告2。我相信，仅仅给出如何重建物体的印象还不够repr …

我最近被告知面向对象编程的一个很好的做法,你应该总是允许从类中继承.我真的不这么认为,但我没有坚定的论据.

阻止继承的真实示例:

1. 没有C++ STL类(专用类模板)允许继承(具有非虚拟析构函数).
2. Java有final类修饰符,适用于许多标准组件,如java.lang.String.

我认为可能的原因是:

1. 安全性,因为子类可能有权访问敏感的内部.(我不这么认为 - 他们不会访问私人会员.)
2. 性能,因为子类可能会通过覆盖某些成员函数来破坏我们的高效实现.(孩子们不会覆盖非虚拟功能.)
3. 到强制组合物过度继承.(我完全同意.如果不需要继承,我们不应该赞成继承.)

所以我的问题是:在什么情况下我应该故意阻止继承？