http://18delphi.blogspot.ru/2013/03/objective-c-delphi.html
Что хочу добавить?
Динамическая типизация и "вызов методов по селектору" - это конечно круто и гибко.
Тем более, что про Python - мне тут уже "плешь проели".
Но я вот год с небольшим программирую на Objective-C параллельно с Delphi, но никак не могу отделаться от мысли, что в Objective-C в отличии от Delphi - я "что-то упускаю"... Что-то проходит мимо меня. Не "держу руку на пульсе".
Особенно это касается "чистого" Objective-C, а не связки Objective-C-C++-STL.
Что мне не хватает "статической типизации" компилятором или хотя бы полной UML-модели.
Приведу пример из реального (почти) проекта.
Есть некий функционал. Он возвращает список неких объектов. Самописных. В виде NSArray.
И функционал - вполне себе работал. И делал то, что надо.
Но потом нашлась ситуация в которой "набивать самописными объектами" NSArray стало "дорого". И стали туда набивать пары "одно число - другое".
А на "клиентском конце" стали смотреть conformsToProtocol. Если conforms - идём по одной ветке - значит там лежат "нужные" объекты, а если не conforms, то по другой. Значит там лежат "нужные пары". В виде NSArray из двух элементов.
Потом случилась ещё одна метаморфоза. И в "тот же самый" список стали помещать proxy-объекты.
А "клиентские концы" - опять модифицировали.
А "клиентских концов" - не один и не два.
И всё - "расползается как тараканы". Если бы это был бы типизированный язык, то компилятор бы это всё показал бы и можно было бы провести дельный (http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D0%B2%D0%B5%D1%89%D0%B8) рефакторинг.
А так.. приходится - "мониторить концы"...
Считайте это "вымышленной историей"... Но поверьте - она - недалека от истины...
И не надо кстати рассказывать, что "надо обобщать клиентские концы". Я КОНЕЧНО это понимаю.
Посему - duck-typing и "вызов метода по селектору" - это КОНЕЧНО - КРУТО и ГИБКО, но ОЧЕНЬ быстро может привести к "аду и ужасу"... Хотя ДАЖЕ GoF - ОЧЕНЬ пропагандируют SmallTalk и его последователей.
И я ИХ ПОНИМАЮ.
Но не могу отделаться от мысли, что "теряю ощущение руки на пульсе".
Никого не хоте обидеть. Просто высказал свои мысли... Если вдруг есть вопросы - задавайте.
P.S. Но! Я не сказал, что Objective-C - "плохой" язык. Нет! Не подумайте этого. Иначе бы я не стал писать его сравнения с Delphi. Но! Objective-C - надо "уметь готовить". Гораздо "осторожнее", чем Delphi. Ну или "понимать грань" и "быстро" переходить от Objective-C к plain-C или C++-STL. Но с "гранью" - непросто.
P.P.S. Это не повод для "РЕЛИГИОЗНЫХ ВОЙН". Это повод - задуматься. И стараться учесть описанные выше ошибки.
Что хочу добавить?
Динамическая типизация и "вызов методов по селектору" - это конечно круто и гибко.
Тем более, что про Python - мне тут уже "плешь проели".
Но я вот год с небольшим программирую на Objective-C параллельно с Delphi, но никак не могу отделаться от мысли, что в Objective-C в отличии от Delphi - я "что-то упускаю"... Что-то проходит мимо меня. Не "держу руку на пульсе".
Особенно это касается "чистого" Objective-C, а не связки Objective-C-C++-STL.
Что мне не хватает "статической типизации" компилятором или хотя бы полной UML-модели.
Приведу пример из реального (почти) проекта.
Есть некий функционал. Он возвращает список неких объектов. Самописных. В виде NSArray.
И функционал - вполне себе работал. И делал то, что надо.
Но потом нашлась ситуация в которой "набивать самописными объектами" NSArray стало "дорого". И стали туда набивать пары "одно число - другое".
А на "клиентском конце" стали смотреть conformsToProtocol. Если conforms - идём по одной ветке - значит там лежат "нужные" объекты, а если не conforms, то по другой. Значит там лежат "нужные пары". В виде NSArray из двух элементов.
Потом случилась ещё одна метаморфоза. И в "тот же самый" список стали помещать proxy-объекты.
А "клиентские концы" - опять модифицировали.
А "клиентских концов" - не один и не два.
И всё - "расползается как тараканы". Если бы это был бы типизированный язык, то компилятор бы это всё показал бы и можно было бы провести дельный (http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D0%B2%D0%B5%D1%89%D0%B8) рефакторинг.
А так.. приходится - "мониторить концы"...
Считайте это "вымышленной историей"... Но поверьте - она - недалека от истины...
И не надо кстати рассказывать, что "надо обобщать клиентские концы". Я КОНЕЧНО это понимаю.
Посему - duck-typing и "вызов метода по селектору" - это КОНЕЧНО - КРУТО и ГИБКО, но ОЧЕНЬ быстро может привести к "аду и ужасу"... Хотя ДАЖЕ GoF - ОЧЕНЬ пропагандируют SmallTalk и его последователей.
И я ИХ ПОНИМАЮ.
Но не могу отделаться от мысли, что "теряю ощущение руки на пульсе".
Никого не хоте обидеть. Просто высказал свои мысли... Если вдруг есть вопросы - задавайте.
P.S. Но! Я не сказал, что Objective-C - "плохой" язык. Нет! Не подумайте этого. Иначе бы я не стал писать его сравнения с Delphi. Но! Objective-C - надо "уметь готовить". Гораздо "осторожнее", чем Delphi. Ну или "понимать грань" и "быстро" переходить от Objective-C к plain-C или C++-STL. Но с "гранью" - непросто.
P.P.S. Это не повод для "РЕЛИГИОЗНЫХ ВОЙН". Это повод - задуматься. И стараться учесть описанные выше ошибки.
Дык эта... тебе-ль не знать ;)
ОтветитьУдалитьЮнитТесты и Бог в помощь. Тем более что они их интегрировали уже вполне дельно в XCode. Пишешь тестик своего выхода, тестик что делает, проверяет что там то что МОЖЕТ быть. Пишешь другой тестик, который скармливает в концы все что попало, ну или то что РЕАЛЬНО может быть, с проевркой, что то что РЕАЛЬНо может быть съели, а то чего быть не должно выплюнули. Ну и все, в любой момент Cmd+U и ты уже в курсе все ли у тебя хорошо. А еще можно тесты автоматом пускать, ну ты понял. Правда в нашем случай это наверное не реально, нужен сервак на OSX... а хто ж его дасть :(
Макс! Блин! "Снял с языка".
УдалитьЯ ХОТЕЛ написать пр ТЕСТЫ.. Но не стал.. Ибо - не "комильфо" я (пока) в тестах под iOS.
А про "новые тесты" - я уже прочитал.. И xCode новый - уже поставил...
Я же написал - "не хочу ругать". Написал "свои ощущения". И кстати - уже думаю - написать продолжение - "как избавится от этих ощущений".
Ну чтобы до конца честным и объективным быть.
"не копенгаген" я хотел сказать :-)
УдалитьНу извини что снял )) ды я и не воспринимаю это как ругань, упаси Господь ;)
Удалитьа тесты,... имхо, они и в африке тесты. Единственное какая тут специфика, дык это способ интеграции в IDE.
Я других (признаюсь) не видел но тут вроде все довольно удобно, хотя я еще не во все въехал, точнее какуюто одну засаду нашел, и не могу понять от чего так...
"Ну извини что снял"
Удалить-- да не.. тут извиняться нечему.. наоборот - клёво.. в одну сторону смотрим...
Про "новые" тесты - я ещё не смотрел.. Меня ОДИН вопрос только в обем интересует - там можно НЕ ВСЕ тесты гонять, а выборочно? В предыдущих версиях - я не нашёл. Тут - есть надежда, что можно...
можно, можно все, можно выбранные, можно по одному прям из кода - прям в редакторе напротив любого тест-метода, маленькая кнопка ПЛЕЙ висит, нажал и конкретно этот тест выполнился
УдалитьНу вот ЭТО - ДАВНО ждал.. ну или чего-то не понимал..
УдалитьКРУТО - коли так.. Есть что делать.. По-уму..
На DUnit это похоже - то, что ты пишешь.
Засада правда в том что почему-то линкер теста не все объектники из своего ТАРГЕТА видит, именно из ТАРГЕТА, вот из библиотек которые с ним линкуется все видит, а из самого таргета - нет. Почему - не въехал, и как лечить тож пока не понимаю. Но это наверное я че-то не так курю.
УдалитьНавскидку я тебе не скажу... Правда "навскидку" - кажется, что это - правильно.. Тесты - связаны именно с целью компиляции.. Концептуально... Могу - ошибаться..
УдалитьНу т.е. идея такая - хочешь тестировать таргеты - тестируй таргеты. И включай тесты в них. Хочешь тестировать БИБЛИОТЕКУ - делай ТАРГЕТ - "тест библиотеки ХХХ" и включай тесты в него.. По-моему - правильно... По-крайней мере я и под Delphi примерно так же и делаю.. ОТДЕЛЬНО тесты библиотек и ОТДЕЛЬНО тесты приложений... Могу конечно ошибаться...
Удалитьтак то оно так, но вот как раз когда я хочу тестировать тАРГЕТ6 то у меня не получается прикрутить к нему тест так, что бы линкер видел объектники из таргета, и либы - пожалуйста.
УдалитьПРИ ЭТОМ, аналогично, если я хочу тестировать либу, ту у меня есть возможность тест прикрутить прямо к ней (ХКоде дает), без создания специального тестирующего приложения-таргета, но по прежнему линекер не видит объектников из этой либы, из другой - пожалуйста. Те линкер все время не видит объектники из того к чему непосредственно прикручен тест.
А еще конечно, нужно набраться сил и все (почти все) ворнинги включить. А там много полезного, особенно про селекторы. Вызвать что попало на чем попало уже на дадут.
ОтветитьУдалитьпро "ворнинги" - тоже "с языка снял".. я их кстати ВСЕ включаю... но там есть проблемы с "портитруемым" кодом".. типа "stdcall"...
УдалитьНо в целом - ты опять прав
ну у нас их там пока дохренищи... надо все вычистить, и поставить ворнинг == еррор. Что бы не повадно было
УдалитьНу я "про нас" кстати - избегаю говорить... Скажем так - вот в SQLite - да.. "тоже" есть...
УдалитьА уж "совсем у нас" - я давно вычистил...
"А там много полезного, особенно про селекторы. "
Удалить"А уж "совсем у нас" - я давно вычистил..."
- про селекторы - особенно.
Про то, что я тут написал - понятное дело - есть "РЕЦЕПТ". Возвращать не NSArray, а СВОЙ объект, агрегирующий ВНУТРИ себя NSArray. О обеспечивающий ВНЕШНИЙ ИНТЕРФЕЙС для "мониторинга концов". Конечно же.
ОтветитьУдалить