1

更新主要问题仍然是示例下的问题，但我想它归结为：

**如果您有一种类型，其中 99% 的值可以用一种快速、强大的类型表示，而只有 1% 的值可以用一种非常重的类型表示，（比如 int 与 BigInteger）如何表示它？**

一所学校，我们学到了很多关于内部表示的知识，但从不知道如何在运行时更改它。我的意思是：假设您有一个表示小数的类，但是您使用整数在内部表示它，直到您实际上需要比整数更大的值，并且仅更改表示形式...

我以前从未想过这一点，当想到它时，我认为这永远不会奏效，因为所有的检查都会杀死它。但是我只是做了一个测试，因为我对自己的利益太好奇了，并且确实存在更改表示方式更持久的情况：给定这个接口：

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);
        }
    }
}

我的问题如下：

这好像…… 我失踪了，但这一定是明显的流血。谁能帮我解决这个问题？

  • 是否有混合表示的指导方针，何时使用它们，何时不使用？
  • 当没有基准测试的混合表示可以更快时，如何有预感？
  • 有什么例子吗？
  • 有什么图案吗？
  • 对此事有任何想法吗？
4

2 回答 2

8

如果您有一种类型，其中 99% 的值可以用一种快速、强大的类型表示，而只有 1% 的值可以用一种非常重的类型表示，（比如 int 与 BigInteger）如何表示它？

BigInteger 实现通常就是这样做的；他们将所有内容保存在 int 或 long 中，直到某些内容溢出，然后才进行更重的实现。

有很多方法可以表示它。我喜欢的一个模式是：

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 的任意数量的实现。

有什么图案吗？

打败了我。我不太喜欢记住模式分类法。

对此事有任何想法吗？

看上面。

于 2009-11-10T21:47:11.253 回答
0

也许您正在寻找Bridge 模式。

于 2009-11-10T20:14:33.953 回答