Предположим, что у нас есть Activity с большим количеством представлений, на которые должен регистрироваться OnClickListener.
Наиболее распространенным способом реализации этого является включение подкласса Activity-Subclass в OnClickListener, что-то вроде этого:
public class ActivityMain extends Activity implements View.OnClickListener
{
@Override
public void onClick(View view)
{
switch (view.getId())
{
//handle multiple view click events
}
}
}
Способ, которым я его реализую, - создать частный класс внутри подкласса Activity и позволить этому внутреннему классу реализовать OnClickListener:
public class ActivityMain extends Activity implements View.OnClickListener
{
private class ClickListener implements View.OnClickListener
{
@Override
public void onClick(View view)
{
switch (view.getId())
{
//handle multiple view click events
}
}
}
}
Таким образом, код выглядит более организованным и простым в обслуживании.
Более того, говоря о связях "Is-a", "Has-a", последнее кажется хорошей практикой, потому что теперь Activity-Subclass будет иметь отношение "Has-a" с ClickListener. Хотя в первом методе мы хотели бы сказать, что "Наша активность-подкласс" Is-a "ClickListener, что не совсем верно.
Обратите внимание, что я не занимаюсь служебными данными памяти, которые вызвали бы последнее.
Кроме того, добавление тега onClick в xml полностью исключается.
Итак, что на самом деле является лучшим способом реализации ClickListener?
Пожалуйста, не предлагайте такие библиотеки, как RoboGuice или ButterKnife и т.д.
UPDATE:
Я хотел бы поделиться подходом, который я наконец принял.
Я непосредственно реализую слушателя в Activity/Fragment.
Что касается дизайна ООП. Подход "HAS-A" не предлагает каких-либо практических преимуществ и даже занимает больше памяти. Учитывая количество вложенных классов (и накладных расходов на память), которые мы будем создавать для каждого подобного слушателя, который мы реализуем, этот подход следует явно избегать.