深度克隆以实现适当的封装
Deep cloning in order to achieve proper encapsulation
我发现 article 关于正确封装的方法。它确实引起了我的注意并解决了我之前的一些困惑。然后我想到了它的实现。不得有公开任何公共引用的任何 属性 或(getter 方法)。为了实现这一点,每个内部领域都必须重新构建。但是并不总是能够了解构造逻辑甚至找到合适的构造函数。所以我认为深度克隆可能用于此目的。
有一些方法可以实现深度克隆(one way, some other ways)。
我的问题是:
1- 我的方法有意义还是完全是胡说八道?
2- 深度克隆操作是否危险或不确定?如果是,那么将这种动态(或不确定)行为用于这样的核心模块(在业务模型 getters 上)是否合适?
PS:就算文章里用了Java,我问的都是.NET或者C#的问题。我不太确定,但 Java 可能具有不同的深度克隆能力。我对 Java.
感到不舒服
Java 和 C# 在含义相同的地方足够接近。
对我来说,这篇文章最好不要发表,因为它唯一的作用就是混淆人们并让他们走上像 "I need to deep clone all my exposed objects in an interface so they can't be changed."
这样的道路
这不是封装的本质。封装的本质是这样的 - 例如 - 给定 public 生日的年龄计算不会暴露:
class foo {
public DateTime Birthdate { get;set;}
public int Age { get { return (DateTime.Now - Birthdate).ToYears(); } }
}
因此,"inner workings"年龄的计算方式没有暴露。或者更确切地说,该逻辑是 encapsulated
现在,有时您确实想要确保公开的对象是完全不可变的,但总的来说,这是无稽之谈。 (深度克隆绝非易事,根本,并且本文没有对问题的更广泛范围提供足够的洞察力,对任何人都没有好处)。
放弃深度克隆暴露的所有内容的想法,只需编写您的 类 并包含其中的逻辑,您将拥有足够好的封装来满足绝大多数目的。
OOP 概念应始终以非常健康的实用主义来理解。
我发现 article 关于正确封装的方法。它确实引起了我的注意并解决了我之前的一些困惑。然后我想到了它的实现。不得有公开任何公共引用的任何 属性 或(getter 方法)。为了实现这一点,每个内部领域都必须重新构建。但是并不总是能够了解构造逻辑甚至找到合适的构造函数。所以我认为深度克隆可能用于此目的。
有一些方法可以实现深度克隆(one way, some other ways)。
我的问题是:
1- 我的方法有意义还是完全是胡说八道?
2- 深度克隆操作是否危险或不确定?如果是,那么将这种动态(或不确定)行为用于这样的核心模块(在业务模型 getters 上)是否合适?
PS:就算文章里用了Java,我问的都是.NET或者C#的问题。我不太确定,但 Java 可能具有不同的深度克隆能力。我对 Java.
感到不舒服Java 和 C# 在含义相同的地方足够接近。
对我来说,这篇文章最好不要发表,因为它唯一的作用就是混淆人们并让他们走上像 "I need to deep clone all my exposed objects in an interface so they can't be changed."
这样的道路这不是封装的本质。封装的本质是这样的 - 例如 - 给定 public 生日的年龄计算不会暴露:
class foo {
public DateTime Birthdate { get;set;}
public int Age { get { return (DateTime.Now - Birthdate).ToYears(); } }
}
因此,"inner workings"年龄的计算方式没有暴露。或者更确切地说,该逻辑是 encapsulated
现在,有时您确实想要确保公开的对象是完全不可变的,但总的来说,这是无稽之谈。 (深度克隆绝非易事,根本,并且本文没有对问题的更广泛范围提供足够的洞察力,对任何人都没有好处)。
放弃深度克隆暴露的所有内容的想法,只需编写您的 类 并包含其中的逻辑,您将拥有足够好的封装来满足绝大多数目的。
OOP 概念应始终以非常健康的实用主义来理解。