Различия между интерфейсами Java и протоколами Objective C?
dragMethod() {
setTimeout( () => {
debugger;
}, 500)
}
Это приостановит действие перетаскивания, чтобы вы могли продолжить проверку как обычно.
2 ответа
Во-первых, небольшая историческая перспектива по теме от одного из создателей Java. Затем в Википедии есть умеренно полезный раздел , посвященный протоколам Objective-C . В частности, следует понимать, что Objective-C поддерживает как формальные протоколы (которые явно объявлены с помощью ключевого слова @protocol , эквивалент интерфейса Java), так и неформальные протоколы (только один или несколько методов, реализованных классом, которые могут быть обнаружены посредством отражения).
Если вы применяете формальный протокол (терминология Objective-C для «реализации интерфейса»), компилятор будет выдавать предупреждения для нереализованных методов, как и следовало ожидать от Java. В отличие от Java (как упомянул скаффман ), если класс Objective-C реализует методы, содержащиеся в формальном протоколе, говорят, что он «соответствует» этому протоколу, даже если его интерфейс не принимает его явно. Вы можете проверить соответствие протокола в коде (используя -conformsToProtocol: ) следующим образом:
if ([myObject conformsToProtocol:@protocol(MyProtocol)]) {
...
}
ПРИМЕЧАНИЕ. В документации Apple говорится:
«Этот метод определяет соответствие исключительно на основе формальные объявления в файлах заголовков, как показано выше. Он не проверяет, реализуются ли методы, объявленные в протоколе, на самом деле - это ответственность программиста ».
Начиная с Objective-C 2.0 (в OS X 10.5» Leopard »и iOS) формальные протоколы теперь могут определять необязательные методы , и класс соответствует протоколу, если он реализует все требуемые методы. Вы можете использовать ключевые слова @required (по умолчанию) и @optional , чтобы переключить, должны ли следующие за объявления методов или быть реализованы соблюдать протокол. (См. Раздел руководства Apple по языку программирования Objective-C 2.0 , в котором обсуждаются дополнительные методы протокола .)
Дополнительные методы протокола открывают разработчикам большую гибкость, особенно при реализации делегирует и слушателей . Вместо расширения чего-то вроде MouseInputAdapter (что может раздражать, поскольку Java также является одинарным наследованием) или реализации множества бессмысленных, пустых методов, вы можете принять протокол и реализовать только те дополнительные методы, которые вам нужны. около. С помощью этого шаблона вызывающая сторона проверяет, реализован ли метод перед его вызовом (используя -respondsToSelector ) следующим образом:
if ([myObject respondsToSelector:@selector(fillArray:withObject:)]) {
[myObject fillArray:anArray withObject:foo];
...
}
Если накладные расходы на отражение становятся проблемой, вы всегда можете кэшировать логический результат для повторного использования , но не поддавайтесь стремлению к преждевременной оптимизации. : -)
Они почти идентичны. Однако одна вещь, которая меня уловила, заключается в том, что если вы явно не заявите, что объективный протокол C также реализует NSObject, ссылки на этот протокол не получают доступа к методам, которые объявляет NSObject (без предупреждения компилятора в любом случае). С помощью java вы можете иметь ссылку на интерфейс и по-прежнему вызывать на нем toString () и т. Д.
например
Objective C:
@protocol MyProtocol
// Protocol definition
@end
id <MyProtocol> myProtocol;
[myProtocol retain] // Compiler warning
Java:
public interface MyInterface {
// interface definition
}
MyInterface myInterface;
myInterface.toString(); // Works fine.
Objective C (исправлено):
@protocol MyProtocol <NSObject>
// Protocol definition
@end
id <MyProtocol> myProtocol;
[myProtocol retain] // No Warning