Pull to refresh

Comments 18

- (NSUInteger)numberOfItemsInSection:(NSUInteger)section 
{
    if (self.loggedIn && section == 0) 
		return 2;
    swtich (section) 
    {
    case 1: 
        if (self.settings.showDetails) 
            return 5;
        else 
	    return 3;
	break;
    case 2:
        return 3;
        break;
    }
}


Я правда не уверен, что знаю что это за язык, но по-моему так проще, не считая магический констант
Уберите else в блоке «case 1». Его смысл вообще смутно понятен в этом случае.
Вообще да, там вообще останется вроде бы нечто подобное:
- (NSUInteger)numberOfItemsInSection:(NSUInteger)section 
{
    if(self.loggedIn && section == 0) 
	    return 2;
    if(self.settings.showDetails && section == 1)
	    return 5;
    return 3;
}

По-моему, особо лучше не стало. А вот с ушедшими фигурными скобками, при усложнении логики есть риск тупейших непоняток при отладке.
Обфускция рулит конешн. Тольк код у вас такж с очпяткми.

Вариант из первого коммента выглядит более читаемым для быстрого «въезжания», чем множество вызовов внутренних методов в вашем коде. Методы оправданы, если в них есть хоть какая-то логика. А если это просто инкапсуляция магических чисел, то овчинка выделки не стоит: создаём пачку именованых констант и всё.
Пачку именованных констант тоже можно обернуть в одну структуру и использовать именно целосное состояние, а не кучку констант.
Простите, метод numberOfItemsInSection: в классе State вызывает self.sections[section] где section это NSUInteger. Может, все-таки, sections это NSArray а не NSDictionary?
Получается, мы один простой и понятный программисту на любом языке свич заменили кодом, который делает непонятно что.
Вы так и не объяснили, зачем бороться со свитчами. Нет, не с конкретным одним свитчем, а вообще со свитчами.
Switch — это инструмент. Вообще, с ним бороться не стоит. Стоит бороться за минимизацию использования switch и if. После получения линейной логики получаем простое понимания кода, и как следствие — быстрое изменение.
После получения линейной логики получаем простое понимания кода, и как следствие — быстрое изменение.

Вы задачу изменили так, что у вас логика стала линейной, или решение?
Нет. Задача осталась прежняя. А код стал линейным. В нем нет ветвлений и вложенных if-else/switch. Просто берем значение, и возвращаем его.
Не, чудес не бывает. Обычно, когда в коде избавляются от свитча (если при этом логика уже была адекватно оптимизирована), свитч либо переносится в другое место (в вашем случае — в выбор класса по секции), либо заменяется на табличный метод (в простом случае — словарь), либо, редко, на всякие частные решения. И тут, собственно, вступает в дело очередной компромис — да, все эти решения делают конкретное место кода более читаемым; но какой ценой? Ценой уменьшения прозрачности и введения лишних косвенных действий. Для одного свитча (с которого вы начали) это бессмысленно; для ситуации, когда много одинаковых свитчей — уже, возможно, нет (хотя опять-таки, есть более одного решения этой проблемы).

Ну и вы, на самом деле, зря считаете, что линейный код, решающий нелинейную задачу — это хорошо и легко в понимании. Лично мне проще, когда я имею дело с конкретной логикой перед глазами, чем отслеживать в какой еще стратегии спрятано конкретное условие обработки.
К сожалению, я часто вижу не просто один switch, а некое месиво вложенных switch и if. Если switch всего один, то не обязательно от него избавиться, но можно уменьшить уровень вложенности switch и if (один из вариантов приведен в ервой части статьи).
Месиво нужно разбирать само по себе и оптимизировать логически. Это не называется «как избавится от свитча», это называется «давайте сделаем логику читаемой».
Sign up to leave a comment.

Articles