- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
switch (SelItemZoom.Text)
{
case "25%":
CRVDoc.Zoom(25);
break;
case "50%":
CRVDoc.Zoom(50);
break;
case "75%":
CRVDoc.Zoom(75);
break;
case "100%":
CRVDoc.Zoom(100);
break;
case "125%":
CRVDoc.Zoom(125);
break;
case "150%":
CRVDoc.Zoom(150);
break;
case "175%":
CRVDoc.Zoom(175);
break;
case "200%":
CRVDoc.Zoom(200);
break;
}
А вообще свитч обладает какой-то особой притягательной силой. Что им только не содят.
Приходилось видеть даже "эмуляцию" полиморфизма в ООП - языке - тупо в базовый класс запихали свитч с проверкой this на тип и выполнением действий в методе в зависимости от этого типа
За такое надо сажать на кол. Или хотя бы в неоплачиваемый отпуск до прочтения GoF
Можно пример?
vs
Первый способ кошернее, второй лаконичнее (и меньше байткода). А теперь представим, что значений десяток и методов несколько.
Ну что ж, добавить throw new AssertionError() не трудно.
Фиксед?
1. if zoom < 25 zoom = 25;
2. if zoom > 200 zoom = 200;
Во-вторых, что делать с промежуточными значениями?
2. выравнивать по ближайшей границе.
скоро код на джаве тоже надо будет разбирать, как клинопись, видя что-то вроде @a++-b()??!c, в голове генерируя незасахаренный код
1. Нет foreach, любая итерация превращается в трехэтажную конструкцию. Да ещё и итерирование по массиву и списку записывается по-разному. Дополнительная переменная на цикл — индекс, итератор или энумератор.
2. Нет генериков, все коллекции безтиповые, при любом обращении приходится явно приводить к нужному типу (и ещё скобочек нужных расставить). Кроме громоздкости, это плохо влияло и на статический контроль типов.
Остальное — просто приятные мелочи.