Как избежать длинных операторов переключения? - PullRequest
Новая
       0

Как избежать длинных операторов переключения?

2 голосов
/ 12 июля 2011

В настоящее время я пишу приложение для Android, которое будет использоваться для подсчета трафика на перекрестках.На пересечении с четырьмя путями приложение будет иметь 24 кнопки.

Существует 4 группы, одна для транспортных средств на восток, юг, запад и север.Каждая из этих 4 групп делится на 2 группы по 3 кнопки для грузовых и легковых автомобилей.Каждая из этих двух групп затем делится на транспортные средства, поворачивающие налево, направо или проезжающие.

Как можно избежать громкого заявления о переключателе / ​​регистре при определении, какая кнопка была нажата?

Что я 'я пытаюсь сделать следующее:

Каждый раз, когда нажимается кнопка, выведите строку с: Тип транспортного средства, Направление, Поворот. 

switch (id) {
    case R.id.car_westbound_left:
        Log.v("output", "car,westbound,left");
        break;
}

и т. д. и т. п.

Теперь я думаю, что это не может быть хорошо написанным кодом.Могу ли я создать класс «Кнопка» с атрибутами: тип транспортного средства, направление, поворот и затем каким-то образом использовать это?но мне все еще нужен идентификатор кнопок, чтобы определить, какая кнопка была нажата?

Ответы [ 3 ]

1 голос
/ 12 июля 2011

Можно установить для свойства тега кнопки (android:tag атрибут XML) значение «car, westbound, left» и извлечь его с помощью метода getTag ().

1 голос
/ 12 июля 2011

Существует множество конструкций для разложения 24-х корпусов от одного длинного "switch" до чего-то другого.Обычные «ОО» подходы заключаются в том, чтобы централизоваться на какой-то фабрике или создать 24 «независимых актера» с полномочиями делать то, что вы хотите.

Например, если вы создали 24 кнопки, которые просто повторяютего запись в журнале, когда нажата, это устранит переключатель.Если у вас есть дополнительная обработка (помимо регистрации), вам необходимо принять стратегическое решение «централизовать» эту обработку (как в одном большом операторе переключения, как у вас сейчас) или «децентрализовать» эту обработку в «независимых субъектов»(например, 24 «умные кнопки»), которые имеют контекст и полномочия делать то, что вы хотите при нажатии.

«Децентрализованный» дизайн может затем созреть: у вас может быть один объект / кнопка «DoIt», с состояние является сообщением журнала, и вы просто создаете экземпляр 24 из этих экземпляров (но имеете только один класс).Даже если 24 экземпляра должны были делать совершенно разные вещи, вы можете дополнительно абстрагировать их в других проектах, например, в создании экземпляров 24 объектов / кнопок, которые ссылаются на 24 различных MyOperation1, MyOperation2, MyOperation3 ... экземпляров класса.

ИМХО, ключевым дизайнерским решением было бы: что вы хотите централизовать?Если они все делают одно и то же, вам нужен один класс с 24 экземплярами.Если они ведут себя принципиально по-разному (у вас есть очень разная логика в каждом из операторов case в вашем switch), то вы можете воспользоваться преимуществами одного или нескольких классов обработки, которые могут иметь общий базовый класс, изатем создайте экземпляр 24 кнопок для каждой ссылки на свой экземпляр класса обработки.

1 голос
/ 12 июля 2011

Как насчет массива строк, где id - это индекс в массиве. Итак, вы получите строку

Log.v("output", myoutputstrings[id]);

Вам просто нужно как-то инициализировать его, возможно прочитать его из файла или базы данных.

...