Пример. Есть интерфейс Packet, есть классы, его реализующие. В интерфейсе логично описать всё поведение пакетов, в том числе должен быть метод, возвращающий, можно ли по указанному протоколу передавать этот пакет. Логично сделать его статическим, так как единственное изменяемое состояние класса, реализующего Packet, — это данные самого пакета, то есть то, что надо передавать на сервер.
А приходится все методы делать или нестатическими, или описывать абстрактный класс со статическими методами, которые надо будет переопределить в унаследованном классе. Но при этом, если программист их не переопределит, ошибки компиляции не будет, но будет логическая ошибка.
В общем, зачем сделали невозможным описание статических методов в интерфейсе?
И как лучше выйти из этой ситуации: абстрактные нестатические методы интерфейсе, статические необязательные к переопределению методы в абстрактном классе или есть ещё варианты?
Я пока склоняюсь ко второму варианту.
Здравствуйте, Donz, Вы писали:
D>Пример. Есть интерфейс Packet, есть классы, его реализующие. В интерфейсе логично описать всё поведение пакетов, в том числе должен быть метод, возвращающий, можно ли по указанному протоколу передавать этот пакет. Логично сделать его статическим, так как единственное изменяемое состояние класса, реализующего Packet, — это данные самого пакета, то есть то, что надо передавать на сервер.
Что ты выиграешь от того что метод будет статическим? Ничего.
D>А приходится все методы делать или нестатическими, или описывать абстрактный класс со статическими методами, которые надо будет переопределить в унаследованном классе. Но при этом, если программист их не переопределит, ошибки компиляции не будет, но будет логическая ошибка.
Нельзя переопределить статический метод. В статике нет полиморфизма.
Ты же вроде не первый день на форуме: http://rsdn.ru/Forum/Message.aspx?mid=1808920&only=1
D>В общем, зачем сделали невозможным описание статических методов в интерфейсе?
Их можно там написать, только они не будут полиморфными. Ещё раз: Зачем тебе приспичила статика?
D>И как лучше выйти из этой ситуации: абстрактные нестатические методы интерфейсе, статические необязательные к переопределению методы в абстрактном классе или есть ещё варианты? D>Я пока склоняюсь ко второму варианту.
Нестатические методы в интерфейсе, они кстати абстрактные в любом случае.
D>Синтаксис языка должен соответствовать JDK 1.1
А он в Java 2 сильно поменялся?
Здравствуйте, Blazkowicz, Вы писали:
D>>Пример. Есть интерфейс Packet, есть классы, его реализующие. В интерфейсе логично описать всё поведение пакетов, в том числе должен быть метод, возвращающий, можно ли по указанному протоколу передавать этот пакет. Логично сделать его статическим, так как единственное изменяемое состояние класса, реализующего Packet, — это данные самого пакета, то есть то, что надо передавать на сервер. B>Что ты выиграешь от того что метод будет статическим? Ничего.
Если по протоколу нельзя передать пакет указанного типа, то не надо будет создавать его объект для того, чтобы это узнать.
B>Нельзя переопределить статический метод. В статике нет полиморфизма. B>Ты же вроде не первый день на форуме: B>http://rsdn.ru/Forum/Message.aspx?mid=1808920&only=1
Пишу на J2ME, ради компактности и быстродействия наследование и, соответственно, полиморфизм применяется, когда от этого уже никуда не деться. Подзабыл из-за малого использования...
D>>И как лучше выйти из этой ситуации: абстрактные нестатические методы интерфейсе, статические необязательные к переопределению методы в абстрактном классе или есть ещё варианты? D>>Я пока склоняюсь ко второму варианту. B>Нестатические методы в интерфейсе, они кстати абстрактные в любом случае.
Описал уже выше. Нет смысла создавать объект, если его нельзя будет использовать, потому что такой тип объекта нельзя передавать по протоколу.
D>>Синтаксис языка должен соответствовать JDK 1.1 B>А он в Java 2 сильно поменялся?
В 1.5 довольно существенно, так как эту версию не использую, то не уверен, что там не ввели что-нибудь, позволяющее найти красивое решение.
Прочитал обсуждение по приведённой ссылке, но так и не понял, почему статические методы сделали непереопределяемыми
Здравствуйте, Donz, Вы писали:
B>>Что ты выиграешь от того что метод будет статическим? Ничего. D>Если по протоколу нельзя передать пакет указанного типа, то не надо будет создавать его объект для того, чтобы это узнать.
Для этого достаточно зарефакторить. Например, сделать фабрику пакетов, которая и будет определять протокол. Хотя если мы все ещё про J2ME в этом тоже не много пользы с точки зрения экономии.
D>Описал уже выше. Нет смысла создавать объект, если его нельзя будет использовать, потому что такой тип объекта нельзя передавать по протоколу.
D>>>Синтаксис языка должен соответствовать JDK 1.1 B>>А он в Java 2 сильно поменялся? D>В 1.5 довольно существенно, так как эту версию не использую, то не уверен, что там не ввели что-нибудь, позволяющее найти красивое решение.
Хорошо. Синтаксис 1.4 чем не подходит? Просто интересно почему 1.1?
D>Прочитал обсуждение по приведённой ссылке, но так и не понял, почему статические методы сделали непереопределяемыми
Потому что поведение класса определяется во время компиляции а не runtime. А полиморфизм должен работать в рантайме.
Здравствуйте, Blazkowicz, Вы писали:
B>>>Что ты выиграешь от того что метод будет статическим? Ничего. D>>Если по протоколу нельзя передать пакет указанного типа, то не надо будет создавать его объект для того, чтобы это узнать. B>Для этого достаточно зарефакторить. Например, сделать фабрику пакетов, которая и будет определять протокол. Хотя если мы все ещё про J2ME в этом тоже не много пользы с точки зрения экономии.
Ну да, можно, примерно так сейчас и сделано. Смотрю тип пакета, смотрю протокол и потом решаю, можно ли передать и, соответственно, надо ли создавать объект. Но мне хотелось бы, чтобы поведение пакета полностью описывалось его свойствами. Как я понял, в данном случае это невозможно.
B>Хорошо. Синтаксис 1.4 чем не подходит? Просто интересно почему 1.1?
В 1.4 есть assert, например.
CLDC 1.0 соответствует JDK 1.1 (сборщик мусора, язык, реализация пакетов java.io и java.lang и т.д., если не ошибаюсь)
B>Потому что поведение класса определяется во время компиляции а не runtime. А полиморфизм должен работать в рантайме.
Поведение класса не определяется в рантайм из-за экономии ресурсов и более широкого анализа возможных ошибок на этапе компиляции?
Здравствуйте, Donz, Вы писали:
D>Пример. Есть интерфейс Packet, есть классы, его реализующие. В интерфейсе логично описать всё поведение пакетов, в том числе должен быть метод, возвращающий, можно ли по указанному протоколу передавать этот пакет. Логично сделать его статическим, так как единственное изменяемое состояние класса, реализующего Packet, — это данные самого пакета, то есть то, что надо передавать на сервер. D>А приходится все методы делать или нестатическими, или описывать абстрактный класс со статическими методами, которые надо будет переопределить в унаследованном классе. Но при этом, если программист их не переопределит, ошибки компиляции не будет, но будет логическая ошибка. D>В общем, зачем сделали невозможным описание статических методов в интерфейсе?
D>И как лучше выйти из этой ситуации: абстрактные нестатические методы интерфейсе, статические необязательные к переопределению методы в абстрактном классе или есть ещё варианты? D>Я пока склоняюсь ко второму варианту.
может не совсем то, но в интерфейсе можно определять статические классы, в том числе и абстрактные
public interface IDataFormatter
{
String format(Object value);
String format(Object[] values);
static abstract class AbstractFormatter implements IDataFormatter
{
public String format(Object[] values)
{
StringBuffer sb = new StringBuffer();
for (int i = 0; i < values.length; i++)
{
sb.append(format(values[i])).append(getDelimeter());
}
return sb.toString();
}
protected abstract String getDelimeter();
public static void main(String[] args)
{
IDataFormatter spaceFormatter = new IDataFormatter.AbstractFormatter()
{
@Override
protected String getDelimeter()
{
return" ";
}
public String format(Object value)
{
return (value != null) ? value.toString() : "";
}
};
Object[] values = new Object[]{"Pi", "=", Double.valueOf(3.14)};
System.out.println(spaceFormatter.format(values));
}
}
}
Здравствуйте, Donz, Вы писали:
B>>Хорошо. Синтаксис 1.4 чем не подходит? Просто интересно почему 1.1? D>В 1.4 есть assert, например. D>CLDC 1.0 соответствует JDK 1.1 (сборщик мусора, язык, реализация пакетов java.io и java.lang и т.д., если не ошибаюсь)
Кажеться, ошибаетесь.
Для мидлетов указанные пакеты совсем другие.
Здравствуйте, aefimov, Вы писали:
B>>>Хорошо. Синтаксис 1.4 чем не подходит? Просто интересно почему 1.1? D>>В 1.4 есть assert, например. D>>CLDC 1.0 соответствует JDK 1.1 (сборщик мусора, язык, реализация пакетов java.io и java.lang и т.д., если не ошибаюсь) A>Кажеться, ошибаетесь. A>Для мидлетов указанные пакеты совсем другие.
Они неполные, то есть содержат не все классы из соответствующих пакетов JDK 1.1
Здравствуйте, aefimov, Вы писали:
A>Отлично смотрится вопрос вместе с футером — Java Fundamentals Master
Знаю, знаю. Как уже писал, на J2ME вкусности ООП применяются редко, так что забывается всё потихоньку за ненужностью
Здравствуйте, Donz, Вы писали:
D>Пример. Есть интерфейс Packet, есть классы, его реализующие. В интерфейсе логично описать всё поведение пакетов, в том числе должен быть метод, возвращающий, можно ли по указанному протоколу передавать этот пакет. Логично сделать его статическим, так как единственное изменяемое состояние класса, реализующего Packet, — это данные самого пакета, то есть то, что надо передавать на сервер. D>А приходится все методы делать или нестатическими, или описывать абстрактный класс со статическими методами, которые надо будет переопределить в унаследованном классе. Но при этом, если программист их не переопределит, ошибки компиляции не будет, но будет логическая ошибка. D>В общем, зачем сделали невозможным описание статических методов в интерфейсе?
D>И как лучше выйти из этой ситуации: абстрактные нестатические методы интерфейсе, статические необязательные к переопределению методы в абстрактном классе или есть ещё варианты? D>Я пока склоняюсь ко второму варианту.
D>Синтаксис языка должен соответствовать JDK 1.1
static — это значит относится именно к тому типу, в котором объявлено. Не к объекту! А интерфейсы — это методы для объектов.
Если ты ищешь логику жизни, то тебе нужно смотреть в сторону паттернов.
Здравствуйте, JINI, Вы писали:
JIN>static — это значит относится именно к тому типу, в котором объявлено. Не к объекту! А интерфейсы — это методы для объектов. JIN>Если ты ищешь логику жизни, то тебе нужно смотреть в сторону паттернов.
У него J2ME, использование паттернов порой вызывает рост результирующего байткода, что является серьезным аргументов для того чтобы от них отказатся.
