Там какой-либо путь состоит в том, чтобы осуществить ввод на NSArray, NSMutableArray, и т.д.?
как ни странно, это было исправлено, когда я добавил промежуточное ПО на экспресс-бэкэнд:
const express = require('express');
const multer = require('multer');
const app = express();
const upload = multer({
dest: './uploads/'
})
app.post('/upload', upload.single('file'), (req, res) => {
res.json({received: 'yes'})
})
app.listen(3344, () => console.log("running on localhost:3344"))
Я до сих пор не знаю, почему это не работает без промежуточного ПО в Firefox, но в Safari это работает .
3 ответа
Вы могли сделать категорию с -addSomeClass: метод, чтобы позволить времени компиляции статическую проверку типа (таким образом, компилятор мог сообщить, пытаетесь ли Вы добавить объект, это знает, другой класс через тот метод), но нет никакого реального способа осуществить это, массив только содержит объекты данного класса.
В целом, кажется, нет потребности в таком ограничении в Objective C. Я не думаю, что когда-либо слышал, что опытный программист Cocoa желает той функции. Единственные люди, которые кажутся, являются программистами с других языков, которые все еще думают на тех языках. Если Вы только хотите объекты данного класса в массиве, только засовываете объекты того класса там. Если Вы хотите протестировать тот свой код, ведет себя правильно, протестируйте его.
Возможный путь мог разделять NSArray на подклассы, но Apple рекомендует не сделать это. Более просто думать дважды о фактической потребности для введенного NSArray.
Это - относительно общий вопрос для людей, переходящих с сильно языков типа (как C++ или Java) к более слабо или динамически типизированные языки как Python, Ruby или Objective C. В Objective C большинство объектов наследовалось NSObject (введите id) (остальные наследовали от другого корневого класса такой как NSProxy и может также быть тип id), и любое сообщение может быть отправлено в любой объект. Конечно, отправка сообщения к экземпляру, что это не распознает, может вызвать ошибку периода выполнения (и также вызовет предупреждение компилятора с соответствующими флагами-W). Пока экземпляр отвечает на сообщение, которое Вы отправляете, Вы не можете заботиться о том, какому классу это принадлежит. Это часто упоминается как "утиный ввод", потому что, "если он шарлатаны как утка [т.е. отвечает на селектор], это - утка [т.е. он может обработать сообщение; кто заботится о том, какой класс это]".
Можно протестировать, отвечает ли экземпляр на селектор во время выполнения с -(BOOL)respondsToSelector:(SEL)selector метод. Принятие Вас хочет назвать метод на каждом экземпляре в массиве, но не уверено, что все экземпляры могут обработать сообщение (таким образом, Вы не можете просто использовать NSArray -[NSArray makeObjectsPerformSelector:], что-то вроде этого работало бы:
for(id o in myArray) {
if([o respondsToSelector:@selector(myMethod)]) {
[o myMethod];
}
}
При управлении исходным кодом для экземпляров, которые реализуют метод (методы), который Вы хотите назвать, более общий подход должен был бы определить a @protocol это содержит те методы, и объявите, что рассматриваемые классы реализуют тот протокол в своем объявлении. В этом использовании, a @protocol походит на Интерфейс Java или абстрактный базовый класс C++. Можно затем протестировать на соответствие к полному протоколу, а не ответ на каждый метод. В предыдущем примере это не имело бы большую часть значения, но если бы Вы называли несколько методов, то это могло бы упростить вещи. Пример затем был бы:
for(id o in myArray) {
if([o conformsToProtocol:@protocol(MyProtocol)]) {
[o myMethod];
}
}
принятие MyProtocol объявляет myMethod. Этот второй подход одобрен, потому что он разъясняет намерение кода больше, чем первое.
Часто, один из этих подходов освобождает Вас от заботы, имеют ли все объекты в массиве данный тип. Если Вы все еще заботитесь, стандартный динамический подход языка к модульному тесту, модульному тесту, модульному тесту. Поскольку регрессия в этом требовании произведет (вероятно, неисправимый) время выполнения (не время компиляции) ошибка, у Вас должно быть тестовое покрытие для проверки поведения так, чтобы Вы не выпускали незваного гостя на волю. В этом случае выполните операцию, которая изменяет массив, затем проверьте, что все экземпляры в массиве принадлежат данному классу. С надлежащим тестовым покрытием Вам даже не нужно добавленное время выполнения наверху проверки идентификационных данных экземпляра. У Вас действительно есть хорошее покрытие модульного теста, не так ли?