在运行时更改内部表示
更新主要问题仍然是示例下的问题，但我想它归结为：
**如果你有一个类型，其中99％的值可以用一个快速，强大的类型表示，而只有1％在非常重的类型中，（比如int与BigInteger）如何表示？ **
一所学校我们学到了很多关于内部表征的知识，但从未在运行时如何改变它。 我的意思是：假设你有一个表示小数的类，但是你使用一个整数来表示它是内部的，直到你实际上需要一个比整数更大的值，而只是改变表示…
我之前从未想过这一点，当我想到这一点时，我认为这样做永远不会奏效，因为所有的检查都会杀掉它。 但是我只是做了一个测试，因为我对自己的好处太好奇了，并且确实存在更改表示更多perormant的情况：给定这个接口：
interface INumber { void add1000(); void SetValue(decimal d); decimal GetValue(); } 我发现两种实现中的后一种在很多情况下都更强大，包括我为了吸引尽可能多的想法（不是代表，它的社区）这个
1. Representation by only a decimal public class Number1:INumber { private decimal d { get; set; } public void add1000() { d += 1000; } public decimal GetValue() { return d; } public void SetValue(decimal d) { this.d = d; } } 2. Representation by a decimal and an int public class Number2:INumber { private bool usedecimal; private int i; private decimal d; public void add1000() { if (usedecimal) { d += 1000; return; } i += 1000; if (i > 2147480000) { d = i; usedecimal = true; } } public void SetValue(decimal d) { try { i = (int)d; } catch (OverflowException e) { this.d = d; } } public decimal GetValue() { return Math.Max(i,d); } } }
我的问题如下：
这似乎是…… 我一直在想，但这肯定是明显的流血。 任何人都可以帮我解决这个问题吗？
- 是否存在混合表示的指南，何时使用它们，何时不使用？
- 如果在没有基准测试的情况下混合重新缓和可以更快，如何预感呢？
- 任何例子？
- 任何模式？
- 关于此事的任何想法？
如果你有一个类型，其中99％的值可以在一个快速，强大的类型中表示，而在非常重的类型中只有1％，（比如int与BigInteger）如何表示它？
BigInteger实现通常就是这样做的; 他们将所有内容保持在整数或长期内，直到某些东西溢出，然后才进入较重的实施。
有很多方法可以代表它。 我喜欢的模式是：
public abstract class Thing { private class LightThing : Thing { ... } private class HeavyThing : Thing { ... } public static Thing MakeThing(whatever) { /* make a heavy or light thing, depending */ } ... etc ... }
是否存在混合表示的指南，何时使用它们，何时不使用？
当然。 我们可以轻松编译这样的列表。 如果：
（1）轻量级实现比重量级实现轻得多
（2）典型用法大部分时间都属于轻量级代码路径
（3）与重量级解决方案的成本相比，检测转换的成本不是显着的成本
（4）为了实现以客户为中心，切合实际的绩效目标，需要更复杂的双表示解决方案。
如果在没有基准测试的情况下混合重新缓和可以更快，如何预感呢？
别。 基于预感做出绩效决策是事先推理的。 在现实的 ，以客户为中心的 ， 数据驱动的分析上推动绩效决策，而不是在预感上。 如果我多年来从性能分析中学到了一点，那我的预感通常是错误的。
任何例子？
BigInteger的任意数量的实现。
任何模式？
打败了我。 我不太喜欢记忆模式分类法。
关于此事的任何想法？
往上看。
也许你正在寻找桥模式 。