Изменение внутреннего представления во время выполнения

Question

UPDATE Основными вопросами остаются те, под примером, но я думаю, это сводится до:

** Если у вас есть тип, где 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);
        }
    }
}

У меня следующий вопрос:

Кажется, что-то. Я скучал, но это должно быть очевидное кровотечение. Кто-нибудь может мне помочь с этим?

• Существуют ли руководящие указания для смешанных представлений, когда их использовать, когда нет?
• Как получить догадку, когда смешанная репрестация может быть быстрее без бенчмаркинга?
• Есть примеры?
• Какие-нибудь шаблоны?
• Есть идеи по этому поводу?

Answer 1

Если у вас есть тип, в котором 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.

Какие-нибудь шаблоны?

Черт побери из меня. Я не очень люблю запоминать шаблонные таксономии.

Есть идеи по этому поводу?

См. Выше.

Answer 2

Возможно, вы ищете шаблон моста .