switch убрать.
От: Аноним  
Дата: 11.06.13 10:49
Оценка:
Здравствуйте, у меня очень простой вопрос(мне думается). Создал класс, а нем метод(см. ниже). Каким образом можно избавиться от switch. Вроде бы так делать не желательно, это же ООП язык и нужно применять, что то более грамотное(полиморфизм и все что с этим связано). Если количество выборок увеличится, то switch станет ну очень неприятным. Есть ли общепринятые методики для таких вот фрагментов?
public void Check_files(string inFile)
        {
            switch (inFile)
            {
                case "txt":
                     ParseTXT();                    
                    break;
                case "conf":
                    ParseConf();
                    break;
                case "log":
                    ParseLog();
                    break; 
                default:
                    CallBacky.callbackEventHandler("Неверный параметр\n");
                    break;
            }
            
        }


С уважением.
Re: switch убрать.
От: Aen Sidhe Россия Просто блог
Дата: 11.06.13 10:59
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, у меня очень простой вопрос(мне думается). Создал класс, а нем метод(см. ниже). Каким образом можно избавиться от switch. Вроде бы так делать не желательно, это же ООП язык и нужно применять, что то более грамотное(полиморфизм и все что с этим связано). Если количество выборок увеличится, то switch станет ну очень неприятным. Есть ли общепринятые методики для таких вот фрагментов?

А>
private Dictionary<string, Action> _d = new Dictionary<string, Action>
{
         { "txt", ParseTXT },
......
}
А>public void Check_files(string inFile)
А>        {
А>              Action actor;
                if(_d.TryGetValue(nFile, out actor))
                     actor();
                else
                    // не нашли
А>        }
А>


А>С уважением.
С уважением, Анатолий Попов.
ICQ: 995-908
Re: switch убрать.
От: Ilinichev  
Дата: 11.06.13 11:00
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, у меня очень простой вопрос(мне думается). Создал класс, а нем метод(см. ниже). Каким образом можно избавиться от switch. Вроде бы так делать не желательно, это же ООП язык и нужно применять, что то более грамотное(полиморфизм и все что с этим связано). Если количество выборок увеличится, то switch станет ну очень неприятным. Есть ли общепринятые методики для таких вот фрагментов?


Какое такое ООП?

using System;
using System.Reflection;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            var str = new string[] { "txt", "conf", "TXT" };

            foreach (var s in str)
            {
                Parse(s);
            }
        }

        static void Parse(string s)
        {
            var bindingFlags = BindingFlags.Static | BindingFlags.InvokeMethod | BindingFlags.IgnoreCase | BindingFlags.NonPublic;

            typeof(Program).InvokeMember("Parse" + s, bindingFlags, null, null, null);
        }

        static void ParseTxt()
        {
            Console.WriteLine("ParseTxt");
        }

        static void ParseConf()
        {
            Console.WriteLine("ParseConf");
        }
    }
}
Re[2]: switch убрать.
От: Ilinichev  
Дата: 11.06.13 11:01
Оценка:
Здравствуйте, Aen Sidhe, Вы писали:

AS>private Dictionary<string, Action> _d = new Dictionary<string, Action>
AS>{
AS>         { "txt", ParseTXT },
AS>......
AS>}


Насколько оправдано здесь применение такой тяжелой структуры данных как Dictionary?
Re: switch убрать.
От: Doc Россия http://andrey.moveax.ru
Дата: 11.06.13 11:12
Оценка: 1 (1)
Здравствуйте, Аноним, Вы писали:

Для 3-5 вариантов не вижу ничего плохого в switch. А вот если больше можно сделать что-то вроде:

Объявить в классе
private readonly Dictionary<string, Action> _actionList;


В конструкторе
this._actionList = new Dictionary<string, Action>() {
    {"txt", this.ProcessTxt},
    {"conf", this.ProcessConf},
    {"log", this.ProcessLog},
};


Ну и использование:
Action action;

if (this._actionsList.TryGetValue(fileType, out action))
    action();
else 
    this.DefaultAction();
Re[3]: switch убрать.
От: Doc Россия http://andrey.moveax.ru
Дата: 11.06.13 11:15
Оценка:
Здравствуйте, Ilinichev, Вы писали:

I>Насколько оправдано здесь применение такой тяжелой структуры данных как Dictionary?


Извините что вопросом на вопрос, но чем лучше использовать Reflection, причем еще обременять класс неявным соглашением об именовании методов.
Re: switch убрать.
От: akasoft Россия  
Дата: 11.06.13 11:15
Оценка: 1 (1) +2
Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, у меня очень простой вопрос(мне думается). Создал класс, а нем метод(см. ниже). Каким образом можно избавиться от switch.


А зачем?

А> Вроде бы так делать не желательно, это же ООП язык и нужно применять, что то более грамотное(полиморфизм и все что с этим связано). Если количество выборок увеличится, то switch станет ну очень неприятным.


И что? Что именно не нравится?
... << RSDN@Home 1.2.0 alpha 5 rev. 66>>
Re[2]: switch убрать.
От: 0x7be СССР  
Дата: 11.06.13 11:15
Оценка: +2
Здравствуйте, Ilinichev, Вы писали:


I>
I>        static void Parse(string s)
I>        {
I>            var bindingFlags = BindingFlags.Static | BindingFlags.InvokeMethod | BindingFlags.IgnoreCase | BindingFlags.NonPublic;

I>            typeof(Program).InvokeMember("Parse" + s, bindingFlags, null, null, null);
I>        }
I>

Фи, рефлексию ради такого дела применять.
Я бы словарь с делегатами забабахал.
Re: switch убрать.
От: 0x7be СССР  
Дата: 11.06.13 11:17
Оценка: 1 (1)
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, у меня очень простой вопрос(мне думается). Создал класс, а нем метод(см. ниже). Каким образом можно избавиться от switch. Вроде бы так делать не желательно, это же ООП язык и нужно применять, что то более грамотное(полиморфизм и все что с этим связано). Если количество выборок увеличится, то switch станет ну очень неприятным. Есть ли общепринятые методики для таких вот фрагментов?

Чтобы ответить на твой вопрос, надо понять, чего ты хочешь в будущем от этого кода.
Re[3]: switch убрать.
От: Mihas  
Дата: 11.06.13 11:18
Оценка:
Здравствуйте, Ilinichev, Вы писали:

I>
AS>>private Dictionary<string, Action> _d = new Dictionary<string, Action>
AS>>{
AS>>         { "txt", ParseTXT },
AS>>......
AS>>}
I>


I>Насколько оправдано здесь применение такой тяжелой структуры данных как Dictionary?


В чем тяжесть?

ИМХО
С одной стороны, инициализация Dictionary выглядит компактнее, чем switch с тем же количеством ветвлений.
С другой стороны, switch гибче, если вдруг сигнатура ParseTXT резко станет отличаться от какого-нибудь ParsePDF.
Re: switch убрать.
От: AK85 Беларусь  
Дата: 11.06.13 11:31
Оценка: +1
Здравствуйте, Аноним, Вы писали:

А>Вроде бы так делать не желательно, это же ООП язык и нужно применять, что то более грамотное(полиморфизм и все что с этим связано).

Полнейший бред.
Switch это элегантная, лекго читаемая и изменяемая конструкция.
Re: switch убрать.
От: Sinatr Германия  
Дата: 11.06.13 11:37
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Каким образом можно избавиться от switch. Есть ли общепринятые методики для таких вот фрагментов?


Есть паттерны ага.

У меня один проект на свитчах, намучался, второй уже писал используя делегаты и функции в виде связанного списка (каждая функция это один из шагов свитча, они выполняются и передают управление дальше, по "траектории", которая определяет поток выполнения).

Первое что можно сделать — это ввести enum для типов:

enum FileType {Txt, Conf, Log, Unknown};


Далее можно пойти по пути TypeConverter — вызывать все обработчики, а уже пусть обработчики решают "могут" они или не могут. Типа:



interface IParse
{
    bool CanParse(FileType file);
    void Parse(...);
}

class ParseLog : IParse
{
    bool CanParse(FileType file) {return file == FileType.Log;}
    void Parse(...) {...}
}

class ParseTxt : IParse
{
    bool CanParse(FileType file) {return file == FileType.Txt;}
    void Parse(...) {...}
}

...

ParseLog _log = new ParseLog();
ParseTxt _txt = new ParseLog();
...

IParse[] _parsers = new IParse[] {_log, _txt, ...};

public bool Parse(FileType file, ...)
{
    foreach(var parser in _parsers)
        if(parser.CanParse(file))
            parser.Parse(...);
}


Возможно есть более кавайное решение для группировки парсеров. В данном случае при добавление нового парсера его нужно происнтансцинировать и добавить в список _list, дальше все работает автоматически.. Оо .. (почти ООП)
---
ПроГLамеры объединяйтесь..
Re[2]: switch убрать.
От: Sinatr Германия  
Дата: 11.06.13 11:39
Оценка:
S>
S>ParseTxt _txt = new ParseTxt();
S>
---
ПроГLамеры объединяйтесь..
Re[2]: switch убрать.
От: hardcase Пират http://nemerle.org
Дата: 11.06.13 11:51
Оценка:
Здравствуйте, Sinatr, Вы писали:

S>Далее можно пойти по пути TypeConverter — вызывать все обработчики, а уже пусть обработчики решают "могут" они или не могут. Типа:


Что делать в случае, когда два парсера заявят о том, что они могут разобрать входные данные?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: switch убрать.
От: Аноним  
Дата: 11.06.13 11:57
Оценка:
Кстати, а можно ли в Dictionary добавить, не вызов функции, а непосредственно код, что то в стиле анонимных функций как в perl?
Re[3]: switch убрать.
От: Sinatr Германия  
Дата: 11.06.13 11:59
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Что делать в случае, когда два парсера заявят о том, что они могут разобрать входные данные?


Возможно именно это как раз и было нужно, раз уж написали 2 парсера? Ведь неизвестно чем является результат работы парсеров. Конфликт по идее можно разрешить просто: первый кто может разобрать (или последний) — разбирает.

А вообще да, еще одно необходимое условие для добавки нового парсера — это добавить в enum понимаемый им FileType. Как-то неподумалось.
---
ПроГLамеры объединяйтесь..
Re[3]: switch убрать.
От: Sinatr Германия  
Дата: 11.06.13 12:04
Оценка:
Здравствуйте, Аноним, Вы писали:

А>можно ли в Dictionary добавить, не вызов функции, а непосредственно код?


Неплохая идея. И кстате да, можно, здесь вот как-бы работает.
---
ПроГLамеры объединяйтесь..
Re: anti-dictionary
От: Ilinichev  
Дата: 11.06.13 12:27
Оценка:
А меня Dictionary всегда смущает. Ведь назначение Dictionary — поиск в больших массивах данных, ну при нескольких сотнях вхождений хотя бы. А тут простая таблица соответствия нужна.
В Reflection тоже не вижу ничего плохого, в более-менее нормальных (особенно UI) приложениях он используется повсеместно, если даже неявно, тем более динамическую привязку можно оптимизировать. Я бы не стал называть использование Reflection обременением за исключением специфичных областей по перелопачиванию огромных массивов информации на скорость.
Соглашение об именовании — это вообще один из столпов программирования.

А для своего личного использования пример с Dictionary (без Reflection) я бы переписал примерно так (для меня гораздо читабельнее, и было бы гораздо легче понять впоследствии, что тут и для чего):

using System;
using System.Linq;
using System.Reflection;

namespace ConsoleApplication1
{
    static class Program
    {
        static ParserEntry[] _parsers = new ParserEntry[] {
            "txt".ParseWith(ParseTxt),
            "conf".ParseWith(ParseConf)
        };

        static ParserEntry ParseWith(this string inFile, Action action)
        {
            return new ParserEntry() { InFile = inFile, Action = action };
        }

        struct ParserEntry
        {
            public string InFile;
            public Action Action;
        }   
        
        static void Main(string[] args)
        {
            var str = new string[] { "txt", "conf", "TXT" };

            foreach (var s in str)
            {
                _parsers.Single(p => string.Compare(s, p.InFile, true) == 0).Action();
            }
        }

        static void ParseTxt()
        {
            Console.WriteLine("ParseTxt");
        }

        static void ParseConf()
        {
            Console.WriteLine("ParseConf");
        }
    }
}
Re[2]: anti-dictionary
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.06.13 12:33
Оценка: 2 (1) +1
Здравствуйте, Ilinichev, Вы писали:

I>А меня Dictionary всегда смущает. Ведь назначение Dictionary — поиск в больших массивах данных


Назначение Dictionary — ассоциативный массив.

I>, ну при нескольких сотнях вхождений хотя бы.


Посмотри как компилятор C# компилирует строковый свитч хотя бы вариантов на 10 — сильно удивишься.

I>В Reflection тоже не вижу ничего плохого


А зря.

I>в более-менее нормальных (особенно UI) приложениях он используется повсеместно


Использоваться он, конечно, используется, то там где можно без него, нужно без него.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK Blog
Re[3]: anti-dictionary
От: Ilinichev  
Дата: 11.06.13 12:49
Оценка: 1 (1)
Здравствуйте, AndrewVK, Вы писали:

I>>А меня Dictionary всегда смущает. Ведь назначение Dictionary — поиск в больших массивах данных

AVK>Назначение Dictionary — ассоциативный массив.

Посредством вычисления хеш-значения. Какова целесообразность этого для десяти постоянных значений?

AVK>Посмотри как компилятор C# компилирует строковый свитч хотя бы вариантов на 10 — сильно удивишься.


Dictionary Но это ведь не значит, что оптимизатор прав, создавая хэш для десяти значений, когда можно обойтись двухстолбцовой таблицей.

I>>в более-менее нормальных (особенно UI) приложениях он используется повсеместно

AVK>Использоваться он, конечно, используется, то там где можно без него, нужно без него.

У ТС, могу предположить, как раз тот случай. Вполне вероятно парсеры у него подключаются как плагины через конфигурационный файл
Re[4]: anti-dictionary
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.06.13 12:53
Оценка:
Здравствуйте, Ilinichev, Вы писали:

I>Посредством вычисления хеш-значения. Какова целесообразность этого для десяти постоянных значений?


Вполне себе.

AVK>>Посмотри как компилятор C# компилирует строковый свитч хотя бы вариантов на 10 — сильно удивишься.

I>Dictionary Но это ведь не значит, что оптимизатор прав

Ну конечно, тебе виднее

I>, создавая хэш для десяти значений, когда можно обойтись двухстолбцовой таблицей.


Что такое "двухстолбцовая таблица"?

AVK>>Использоваться он, конечно, используется, то там где можно без него, нужно без него.

I>У ТС, могу предположить, как раз тот случай.

Это почему это? Его задача хорошо решается и без рефлекшена.

I> Вполне вероятно парсеры у него подключаются как плагины через конфигурационный файл


Да да, а потом варианты хардкодятся в switch
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK Blog
Re[2]: anti-dictionary
От: Doc Россия http://andrey.moveax.ru
Дата: 11.06.13 12:53
Оценка:
Здравствуйте, Ilinichev, Вы писали:

I>Соглашение об именовании — это вообще один из столпов программирования.


Вы ничего не путаете? Потом поддерживать такое соглашения бывает очень не просто (особенно если чужой код с плохой документацией).
Re: switch убрать.
От: andyag  
Дата: 11.06.13 12:56
Оценка:
Здравствуйте, Аноним, Вы писали:

А> Есть ли общепринятые методики для таких вот фрагментов?


Ну вот так например:

    class Program
    {
        static void Main(string[] args)
        {
            var magicChecker = new MagicCheckerBuilder()
                .WithParser("txt", new TxtParser())
                .WithParser("conf", new ConfParser())
                .WithParser("log", new LogParser())
                .Build();

            var yourService = new YourService(magicChecker);
            yourService.CheckFiles("conf");
        }
    }

    public class YourService
    {
        private readonly MagicChecker _magicChecker;

        public YourService(MagicChecker magicChecker)
        {
            _magicChecker = magicChecker;
        }

        public void CheckFiles(string inFile)
        {
            _magicChecker.MagicallyCheck(inFile);
        }
    }

    public class MagicChecker
    {
        private readonly IDictionary<string, IParser> _parsers;

        public MagicChecker(IDictionary<string, IParser> parsers)
        {
            _parsers = parsers;
        }

        public void MagicallyCheck(string inFile)
        {
            var haveNoIdeaWhatToDo = !_parsers.ContainsKey(inFile);
            if (haveNoIdeaWhatToDo)
            {
                throw new Exception("Have no idea what to do");
            }

            var parser = _parsers[inFile];
            parser.Parse();
        }
    }

    public class MagicCheckerBuilder
    {
        private readonly IDictionary<string, IParser> _parsers = new Dictionary<string, IParser>();

        public MagicCheckerBuilder WithParser(string inFile, IParser parser)
        {
            _parsers.Add(inFile, parser);
            return this;
        }

        public MagicChecker Build()
        {
            return new MagicChecker(_parser);
        }
    }

    public interface IParser
    {
        void Parse();
    }

    public class TxtParser : IParser
    {
        public void Parse()
        {
            throw new NotImplementedException();
        }
    }

    public class ConfParser : IParser
    {
        public void Parse()
        {
            throw new NotImplementedException();
        }
    }

    public class LogParser : IParser
    {
        public void Parse()
        {
            throw new NotImplementedException();
        }
    }
Re[4]: ListDictionary и HybridDictionary
От: igor-booch Россия  
Дата: 11.06.13 13:13
Оценка: 2 (1)
I>>>А меня Dictionary всегда смущает. Ведь назначение Dictionary — поиск в больших массивах данных
AVK>>Назначение Dictionary — ассоциативный массив.
I>Посредством вычисления хеш-значения. Какова целесообразность этого для десяти постоянных значений?

Согласен с тобой,
Dictionary предназначен для ассоциативного массива из большого количества элементов.
Если количество элементов мало, то можно использовать
http://msdn.microsoft.com/en-us/library/system.collections.specialized.listdictionary.aspx

Если неизвестно
http://msdn.microsoft.com/en-us/library/system.collections.specialized.hybriddictionary.aspx

К сожалению они не тапизированные
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[2]: switch убрать.
От: Ilinichev  
Дата: 11.06.13 13:13
Оценка:
Здравствуйте, andyag, Вы писали:

Если .net 4.5, предложу внутри MagicChecker использовать ReadOnlyDictionary
Re[5]: ListDictionary и HybridDictionary
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.06.13 13:22
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>К сожалению они не тапизированные


Написать на коленке типизированные недолго, благо ListDictionary примитивен донельзя. Вот только будет ли выигрыш заметный — большой вопрос.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK Blog
Re[6]: ListDictionary и HybridDictionary
От: igor-booch Россия  
Дата: 11.06.13 13:31
Оценка:
AVK>Написать на коленке типизированные недолго, благо ListDictionary примитивен донельзя. Вот только будет ли выигрыш заметный — большой вопрос.

Зависит от того сколько раз будет вызывать код с ListDictionary, если один раз в день, то выигрыша не будет.
Если 1000 раз в сек, то выигрыш будет.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[7]: ListDictionary и HybridDictionary
От: fddima  
Дата: 11.06.13 14:07
Оценка:
Здравствуйте, igor-booch, Вы писали:

AVK>>Написать на коленке типизированные недолго, благо ListDictionary примитивен донельзя. Вот только будет ли выигрыш заметный — большой вопрос.

IB>Зависит от того сколько раз будет вызывать код с ListDictionary, если один раз в день, то выигрыша не будет.
IB>Если 1000 раз в сек, то выигрыш будет.
Учитывая что у ТС — там парсинг лога / кофиг, файловый IO — этой разницы не будет видно даже в электронный микроскоп.
Re[8]: ListDictionary и HybridDictionary
От: Ilinichev  
Дата: 11.06.13 14:19
Оценка:
Здравствуйте, fddima, Вы писали:

AVK>>>Написать на коленке типизированные недолго, благо ListDictionary примитивен донельзя. Вот только будет ли выигрыш заметный — большой вопрос.

IB>>Зависит от того сколько раз будет вызывать код с ListDictionary, если один раз в день, то выигрыша не будет.
IB>>Если 1000 раз в сек, то выигрыш будет.
F> Учитывая что у ТС — там парсинг лога / кофиг, файловый IO — этой разницы не будет видно даже в электронный микроскоп.

Боюсь вас огорчить, но электронный микроскоп не профайлит
Re[9]: ListDictionary и HybridDictionary
От: fddima  
Дата: 11.06.13 14:25
Оценка: +1
Здравствуйте, Ilinichev, Вы писали:

F>> Учитывая что у ТС — там парсинг лога / кофиг, файловый IO — этой разницы не будет видно даже в электронный микроскоп.

I>Боюсь вас огорчить, но электронный микроскоп не профайлит
А профайлить и не надо, что бы понять, что методы Parse* будут занимать 99.9% времени.
Re[7]: ListDictionary и HybridDictionary
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.06.13 15:12
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Если 1000 раз в сек, то выигрыш будет.


Откуда такая уверенность?
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK Blog
Re: switch убрать.
От: Аноним  
Дата: 11.06.13 15:31
Оценка: :)
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, у меня очень простой вопрос(мне думается). Создал класс, а нем метод(см. ниже). Каким образом можно избавиться от switch. Вроде бы так делать не желательно, это же ООП язык и нужно применять, что то более грамотное(полиморфизм и все что с этим связано). Если количество выборок увеличится, то switch станет ну очень неприятным. Есть ли общепринятые методики для таких вот фрагментов?



Если с т.з. именно ООП то по идее так


////////
// ИНТЕРФЕЙС И ФАБРИКА ДЛЯ СОЗДАНИЯ ОБЪЕКТОВ 
/////////
public interface IParser
{
   void Parse();
}

public static class ParserFactory
{
    // Эту штуку можно динамически создавать из app.config например
    static ReadOnlyDictionary<string,Type> _parsersNameTypeMap
    {
      {"txt", typeof(TextParser)}
      {"cfg", typeof(ConfigParser)}
    }

    public static IParser CreateFromExtension( string extension )
    {
       if (!_parsersNameTypeMap.ContainsKey(extension))
          throw new ArgumentException("Неизвестное расширение '" + extension + "'" );

       var parser = Activator.CreateInstance( _parserNameTypeMap[ extension ] ) as IParser; 
       if ( parser == null )
          throw new ArgumentException("Для расширения '" + extension + "' задан тип  не совместимый с интерфейсом IParser");

       return parser;
    }
}

/////////////////
// Описание различных алгоритмов парсинга
/////////////////

public class TextParser : IParser
{
   void Parse()
   {
      //....
   }
}

public class ConfigParser : IParser
{
   void Parse()
   {
   }
}
Re[7]: ListDictionary и HybridDictionary
От: fddima  
Дата: 11.06.13 20:35
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Зависит от того сколько раз будет вызывать код с ListDictionary, если один раз в день, то выигрыша не будет.

IB>Если 1000 раз в сек, то выигрыш будет.
Дабы закончить свою мысль. Всё дело в если. В ListDictionary и их аналогах есть свои нюансы как и в обычном Dictionary. У Dictionary будет несколько большая косвенность, зато оно даст константное среднее время доступа, а ListDictionary — никогда. Если "1000 раз в сек" спрашивать 10-ый элемент? Но это ерунда.
А, если у нас 3-5 варианта выбора. А, если мы накладываем ограничение, что поданная строка должна быть пропущена через таблицу символов (а-ля интернирована), то банальный if-else с простым сравнением ссылок порвёт любой вариант Dictionary.
Ещё не много если? А если у нас парсер парсит лог секунду (или скажем поближе к реальности — минуты две), толку то.
Микробенчмарки не только нынче не в моде, а ещё и полностью бесполезны, т.к. доступ к памяти — вещь очень неконстантная и зависит собственно от загрузки хоста. Все остальные критерии ничего не значит, код должен быть понятен и прост насколько это возможно (при прочих равных показателях).
Лучше вот тут бы предложил http://www.rsdn.ru/forum/dotnet/5196714.1
Автор: Нахлобуч
Дата: 10.06.13
что-нибудь интересное, где действительно имеет смысл повыжимать биты.
Re[2]: switch убрать.
От: igor-booch Россия  
Дата: 12.06.13 08:48
Оценка:
S>У меня один проект на свитчах, намучался

А в чем заключались мучения?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[3]: switch убрать.
От: Sinatr Германия  
Дата: 12.06.13 09:02
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>У меня один проект на свитчах, намучался

IB>А в чем заключались мучения?

Сначала все было хорошо, потом появились case внутри которых был довольно увесистый блок кода (а выносить в отдельную функцию было накладно, т.к. много локальных переменных использовалось в самом коде), потом появилась необходимость заводить локальные и глобальные переменные для определенных case-ов, потом появилась необходимость выполнить несколько свитчей за раз и вернутся (что-то вроде вызова подпрограммы, выполняющей шаг, который используется в нескольких местах) и тд.

Новый проект писал с делегатами.. стало как-то красиво и легко вдруг (именно сапортить легко). Словами не обьяснить, понимание приходит когда количество case-ов за 50.
---
ПроГLамеры объединяйтесь..
Re[4]: switch убрать.
От: Yoriсk  
Дата: 12.06.13 09:39
Оценка: +1
Здравствуйте, Sinatr, Вы писали:

S>Сначала все было хорошо, потом появились case внутри которых был довольно увесистый блок кода (а выносить в отдельную функцию было накладно, т.к. много локальных переменных использовалось в самом коде), потом появилась необходимость заводить локальные и глобальные переменные для определенных case-ов, потом появилась необходимость выполнить несколько свитчей за раз и вернутся (что-то вроде вызова подпрограммы, выполняющей шаг, который используется в нескольких местах) и тд.


И как так выходит, что выносить в отдельную функцию — накладно, а с делегатом(по сути — такой же функцией только вид сбоку) — красиво и легко?
Re[5]: switch убрать.
От: Sinatr Германия  
Дата: 12.06.13 09:50
Оценка: -2 :)))
Здравствуйте, Yoriсk, Вы писали:

Y>И как так выходит, что выносить в отдельную функцию — накладно, а с делегатом(по сути — такой же функцией только вид сбоку) — красиво и легко?


Это уже придирки. Но если смотреть на switch/case в любом виде (будь там код или вызовы отдельных функций), то это больше похоже на кашу, в которой сложно разобраться (когда необходимо внести изменения через год или вообще другому человеку). С функциями и делегатами выглядит более элегантно что ли.

Понятно, что switch/case нужны и полезны, но в определенных случаях ими пользоваться неудобно. Взять пример ТС и 50 парсеров — получится каша. Если много чего-то "похожего", то программист всегда предпочтет организовать это в цикле. Исключение — если нужна оптимизация по скорости или индусский код.
---
ПроГLамеры объединяйтесь..
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.