почему objective-c не поддерживает частные методы?

<p>я видел несколько стратегий для объявления полуприватных методов в <strong>objective-c</strong>, но, похоже, нет способа создать действительно приватный метод. я принимаю это. но почему это так? каждое объяснение, которое я, по сути, говорю: "вы не можете сделать это, но вот близкое приближение".</p><p>существует несколько ключевых слов, примененных к <code>ivars</code> (участники), которые управляют их областью действия, например, <code>@private</code>, <code>@public</code>, <code>@protected</code>. почему это нельзя сделать и для методов? кажется, что-то, что среда выполнения должна поддерживать. есть ли основополагающая философия, по которой я скучаю? это умышленно?</p>

<p>ответ ... ну ... просто. простота и последовательность, на самом деле.</p><p>objective-c является чисто динамическим в момент отправки метода. в частности, каждая отправка метода проходит через ту же точку разрешения динамического метода, что и любая другая отправка метода. во время выполнения каждая реализация метода имеет одинаковую экспозицию, и все api-интерфейсы, предоставляемые средой выполнения objective c, которые работают с методами и селекторами, одинаково работают во всех методах.</p><p>как многие ответили (и здесь, и в других вопросах), поддерживаются частные методы времени компиляции; если класс не объявляет метод в своем общедоступном интерфейсе, то этот метод может также не существовать в том, что касается вашего кода. другими словами, вы можете достичь всех различных комбинаций видимости, требуемых во время компиляции, правильно организовав свой проект.</p><p>нет смысла дублировать ту же функциональность во время выполнения. это добавило бы огромное количество сложности и накладных расходов. и даже несмотря на всю эту сложность, это все равно не помешало бы всем, кроме самого случайного разработчика, использовать ваши предположительно "частные" методы.</p><blockquote> <p>правка: одно из предположений, которые я заметил, заключается в том, что личные сообщения должны проходить во время выполнения, что может привести к потенциально большим издержкам. это абсолютно верно?</p> <blockquote> <p>да, это. нет оснований предполагать, что разработчик класса не захочет использовать весь набор функций objective-c в реализации, а это означает, что должна происходить динамическая диспетчеризация. <em>однако</em>, нет особой причины, по которой частные методы не могут быть отправлены специальным вариантом <code>objc\_msgsend()</code>, так как компилятор будет знать, что они являются закрытыми; это может быть достигнуто путем добавления таблицы методов только для частного использования в структуру <code>class</code>.</p> </blockquote> <p>для частного метода не было бы способа замкнуть эту проверку или пропустить время выполнения?</p> <blockquote> <p>он не мог пропустить среду выполнения, но среда выполнения <em>не будет</em> обязательно должна выполнять какую-либо проверку для закрытых методов.</p> <p>тем не менее, нет никаких причин, по которым сторонние разработчики не могли бы намеренно вызывать <code>objc\_msgsendprivate()</code> для объекта вне реализации этого объекта, и некоторые вещи (например, kvo) должны были бы это сделать. по сути, это было бы просто соглашение и немного лучше на практике, чем префикс селекторов частных методов или не упоминание их в заголовке интерфейса.</p> </blockquote> </blockquote><p>однако это подорвало бы чисто динамическую природу языка. больше не будет отправка каждого метода через идентичный механизм отправки. вместо этого вы окажетесь в ситуации, когда большинство методов ведут себя одинаково, а небольшая кучка просто различна.</p><p>это выходит за рамки времени выполнения, поскольку в какао существует множество механизмов, построенных на основе согласованного динамизма objective-c. например, и кодирование значения ключа, и наблюдение значения ключа должны были бы быть либо сильно изменены, чтобы поддерживать частные методы - скорее всего, путем создания уязвимой лазейки - либо частные методы были бы несовместимы.</p>

<p>время выполнения могло бы поддержать это, но стоимость была бы огромна. каждый отправленный селектор должен быть проверен на то, является ли он закрытым или общедоступным для этого класса, или каждый класс должен управлять двумя отдельными таблицами отправки. это не то же самое для переменных экземпляра, потому что этот уровень защиты выполняется во время компиляции.</p><p>кроме того, среда выполнения должна проверить, что отправитель личного сообщения принадлежит к тому же классу, что и получатель. вы также можете обойти частные методы; если класс использует <code>instancemethodforselector:</code>, он может передать возвращенное <code>imp</code> любому другому классу, чтобы они могли напрямую вызывать закрытый метод.</p><p>частные методы не могли обойти отправку сообщения. рассмотрим следующий сценарий:</p><ol> <li> <p>класс <code>allpublic</code> имеет открытый метод экземпляра <code>dosomething</code></p> </li> <li> <p>другой класс <code>hasprivate</code> имеет закрытый метод экземпляра, также называемый <code>dosomething</code></p> </li> <li> <p>вы создаете массив, содержащий любое количество экземпляров <code>allpublic</code> и <code>hasprivate</code></p> </li> <li> <p>у вас есть следующий цикл:</p> <pre><code>for (id anobject in myarray) [anobject dosomething]; </code></pre> <p>если вы запустили этот цикл из <code>allpublic</code>, среда выполнения остановит отправку <code>dosomething</code> на экземпляры <code>hasprivate</code>, однако этот цикл можно будет использовать, если он находится внутри класса <code>hasprivate</code>.</p> </li> </ol>

<p>ответы, опубликованные до сих пор, дают хорошую возможность ответить на вопрос с философской точки зрения, поэтому я собираюсь изложить более прагматичную причину: что можно было бы получить, изменив семантику языка? это достаточно просто, чтобы эффективно "скрыть" приватные методы. например, представьте, что у вас есть класс, объявленный в заголовочном файле, например:</p><pre><code>@interface myobject : nsobject {} - (void) dosomething; @end </code></pre><p>если вам нужны "приватные" методы, вы также можете поместить это в файл реализации:</p><pre><code>@interface myobject (private) - (void) dosomehelperthing; @end @implementation myobject - (void) dosomething { // do some stuff [self dosomehelperthing]; // do some other stuff; } - (void) dosomehelperthing { // do some helper stuff } @end </code></pre><p>конечно, это не <em>вполне</em> то же самое, что частные методы c++/java, но он достаточно близок, поэтому зачем менять семантику языка, а также компилятор, среду выполнения и т.д., чтобы добавить функция, которая уже эмулируется приемлемым образом? как отмечалось в других ответах, семантика передачи сообщений - и их зависимость от отражения во время выполнения - сделают обработку "личных" сообщений нетривиальной.</p>

<p>самое простое решение - просто объявить некоторые статические функции c в ваших классах objective-c. они имеют только файловую область в соответствии с правилами c для статического ключевого слова, и поэтому они могут использоваться только методами в этом классе.</p><p>никакой суеты вообще.</p>

<p>да, это можно сделать, не затрагивая среду выполнения, используя технику, уже использованную компилятором (-ами) для обработки c++: именование.</p><p>это не было сделано, потому что не было установлено, что это решило бы некоторую значительную трудность в пространстве проблем кодирования, которую другие методы (например, префикс или подчеркивание) способны обойти в достаточной степени. iow, вам нужно больше боли, чтобы преодолеть укоренившиеся привычки.</p><p>вы можете добавить патчи в clang или gcc, которые добавляют частные методы к синтаксису и генерируют искаженные имена, которые он один распознал во время компиляции (и быстро забыл). тогда другие члены сообщества objective-c смогут определить, действительно ли это того стоило или нет. вероятно, так будет быстрее, чем пытаться убедить разработчиков.</p>

<p>по сути, это связано с формой вызовов методов в objective-c. любое сообщение может быть отправлено любому объекту, и объект выбирает, как ответить на сообщение. обычно он отвечает, выполняя метод, названный в честь сообщения, но он также может отвечать и другими способами. это не делает частные методы совершенно невозможными - ruby делает это с аналогичной системой передачи сообщений - но это делает их несколько неловкими.</p><p>даже реализация частных методов в ruby немного смущает людей из-за странности (вы можете отправлять объекту любое сообщение, которое вам нравится, <em>кроме тех, что в этом списке</em>!). по сути, ruby заставляет его работать, запрещая частным методам вызываться с явным получателем. в objective-c это потребовало бы еще больше работы, поскольку objective-c не имеет такой возможности.</p>

<p>это проблема со средой выполнения objective-c. <a href="http://en.wikipedia.org/wiki/objective-c#philosophical\_differences\_between\_objective-c\_and\_c.2b.2b">хотя c/c++</a> компилируется в нечитаемый машинный код, <a href="http://osmorphis.blogspot.com/2009/05/reflection-in-objective-c.html">objective-c по-прежнему поддерживает некоторые удобочитаемые атрибуты, такие как имена методов в виде строк</a> . это дает objective-c возможность выполнять <a href="http://en.wikipedia.org/wiki/reflection\_(computer\_science)">отражающие</a> функции.</p><p><strong> редактировать: </strong> быть рефлексивным языком без строгих закрытых методов делает objective-c более "питоническим", поскольку вы доверяете другим людям, которые используют ваш код, а не ограничивают методы, которые они могут вызвать. использование соглашений об именах, таких как двойное подчеркивание, предназначено для того, чтобы скрыть ваш код от обычного клиентского кодера, но не остановит кодеров, которым требуется более серьезная работа.</p>

<p>есть два ответа в зависимости от толкования вопроса.</p><p>первый - это скрыть реализацию метода от интерфейса. это используется, как правило, с категорией без имени (например, <code>@interface foo()</code>). это позволяет объекту отправлять эти сообщения, но не другие - хотя можно все равно случайно (или иным образом) переопределить.</p><p>второй ответ, при условии, что речь идет о производительности и встраивании, возможен, но вместо этого, как локальная функция си. если вам нужен метод ‘private foo (<code>nsstring *arg</code>), вы должны выполнить <code>void myclass\_foo(myclass *self, nsstring *arg)</code> и вызвать его как функцию c, например <code>myclass\_foo(self,arg)</code>. синтаксис другой, но он действует с нормальными характеристиками производительности частных методов c++.</p><p>хотя это отвечает на этот вопрос, я должен отметить, что категория без имен - гораздо более распространенный способ сделать это в objective-c.</p>

<p>objective-c не поддерживает частные методы, потому что они не нужны.</p><p>в c++ каждый метод должен быть видимым в объявлении класса. у вас не может быть методов, которые кто-то, включая файл заголовка, не может увидеть. поэтому, если вы хотите, чтобы методы, которые не использовались в коде вне вашей реализации, у вас нет выбора, компилятор должен предоставить вам какой-то инструмент, чтобы вы могли сказать ему, что метод не должен использоваться, то есть ключевое слово "private".</p><p>в objective-c у вас могут быть методы, которых нет в заголовочном файле. таким образом, вы очень легко достигаете той же цели, не добавляя метод в заголовочный файл. там нет необходимости в частных методах. objective-c также имеет то преимущество, что вам не нужно перекомпилировать каждого пользователя класса, потому что вы изменили приватные методы.</p><p>для переменных экземпляра, которые вы должны были объявить в заголовочном файле (больше нет), доступны @private, @public и @protected.</p>

<p>здесь отсутствует ответ: частные методы - плохая идея с точки зрения эволюционируемости. может показаться хорошей идеей сделать метод закрытым при его написании, но это форма раннего связывания. контекст может измениться, и более поздний пользователь может захотеть использовать другую реализацию. немного провокационно: "проворные разработчики не используют частные методы"</p><p>в некотором смысле, как и smalltalk, objective-c предназначен для взрослых программистов. мы ценим знание того, каким первоначальный разработчик предполагал, что интерфейс должен быть, и берем на себя ответственность за последствия, если нам нужно изменить реализацию. так что да, это философия, а не реализация.</p>