Rails: каковы основные причины для того, чтобы сделать методы приватными?

Question

Если end_user не может получить доступ к исходному коду приложения, почему нам все еще нужно сделать некоторые методы закрытыми?

Я читаю Pragmatic Agile Web Development с Rails, и я не мог понять, почему мы должны сделать следующий метод закрытым (даже после прочтения объяснения):

private
  def current_cart Cart.find(session[:cart_id])
   rescue ActiveRecord::RecordNotFound 
   cart = Cart.create 
   session[:cart_id] = cart.id
   cart
   end 
end

В нем говорится, что он никогда не позволит Rails сделать его доступным как действие, но как кодер, зачем мне это делать самому?

Answer 1

Как вы говорите, не может быть никаких внешних причин делать это частным.Однако это также предотвращает случайное использование вами (или кем-то еще, использующим ваш код) метода, в котором вы не должны этого делать.

Рассматривайте это как проверку здравого смысла в вашем будущем поведении, если хотите.

Answer 2

Он направлен на поощрение хороших практик и хорошего кода.

Идея состоит в том, что у вас есть две отдельные части в вашем коде:

"Над строкой" (Public).Это интерфейс с остальным миром.Это API, в котором выполняются вызовы при использовании экземпляров объекта.После создания вы знаете, что ЭТО - область, в которой изменения могут повлиять на текущее использование кода.

"Под чертой (Приват). Здесь находится подробная логика. Этот код можно свободно изменять и реорганизовывать безлюбое влияние на общедоступный интерфейс.

Это может помочь при написании теста

• Частные методы могут или не могут быть (единичными) проверены.
• Публичные методыболее обнадеживающие как модульные, так и интегрированные тесты, так как тот факт, что он является публичным, означает, что он служит публичным лицом для этого кода, и, поскольку он является публичным, его можно вызывать с любого другого момента в будущем, так что наличие хороших тестов дляважно, чтобы он продолжал работать так, как объявлено, - это важно.

Это может помочь с безопасностью, поскольку у вас есть больший контроль над тем, кто вызывает частные методы (то есть только публичные методы в том же классе, вызывающем их).

Это может помочь уменьшить коллизии имен, так как у вас меньше имен в публичном пространстве.

Answer 3

Есть несколько причин, как указано выше.Интересно, что эта инкапсуляция в ruby ​​может быть нарушена.

См. Метод " send " и его брат " public_send ".

И для очень распространенного метода метапрограммирования, использующего этот метод, см .:

динамические искатели

Answer 4

В нем говорится, что он никогда не позволит Rails сделать его доступным как действие,

Хмм, это класс Rails Conroller?И написана ли книга, над которой вы работаете, для Rails 2.x?

В Rails 2.x по умолчанию любой публичный метод в контроллере может быть вызван кем-то, обращающимся к URL /name_of_controller / name_of_method.

Но в вашем контроллере есть несколько методов, которые вы не хотите, чтобы кто-либо в сети вызывал, они не были предназначены как «методы действия».Поэтому в Rails 2.x вы помечаете их как protected или private, что-то не публичное.«Метод действия» означает метод, который вы собираетесь запускать напрямую через URL.

В Rails 3.x маршрутизация, как правило, изменилась так, что только определенные методы, на которые вы явно направляете маршруты, доступны для запуска через URL.Тем не менее, возможно, все же имеет смысл пометить неактивные методы в Контроллере как защищенные или закрытые, поэтому:

• Из анализа источника более ясно, какие методы являются методами действия, а какие нет
• В качестве меры предосторожности на случай, если кто-то изменит маршрутизацию таким образом, чтобы URL мог запускать те методы, которые не предназначены в качестве методов действия

Или по общим причинам организации кода, что другоев ответах упоминается, что они не относятся к классам контроллеров Rails.

Answer 5

Конечный пользователь может не иметь доступа к вашему коду, но кто-то в вашей команде может получить к нему доступ, и он может изменить его.

Другим преимуществом инкапсуляции является то, что она позволяет одному классу («серверу») заключать контракт с другим классом («клиентом») для предоставления некоторого сервиса, при этом требуется лишь очень немного информации о «сервере». msgstr "класс, такой как сигнатура метода и тип возвращаемого значения. Выгода реализуется только в том случае, если договор о том, что требуется и что возвращается, остается прежним. Таким образом, в вашем примере, вы не получите никакой выгоды, поскольку контракт был нарушен классом А.

Вместо того, чтобы класс A изменил тип int на float, класс A должен создать еще одну новую переменную типа float для использования другими классами, чтобы класс B не был "нарушен" или чтобы контракт не разрывался между ними. Класс C может ссылаться на новую переменную с плавающей точкой, а класс B может ссылаться на старую переменную int, и все довольны. Более того, методы будут использоваться для получения значений, таких как: «getUsersAddress» и «getUSersPhoneNumber» в зависимости от того, что требуется.

Реальное преимущество хорошей инкапсуляции состоит в том, что класс A может быть полностью переписан сверху вниз и при условии соблюдения контракта относительно того, что ожидается от класса A (есть методы "getUsersAddress" и "getUSersPhoneNumber" ), то все в классах B и C работает одинаково. Тщательно продумайте, что подвергается воздействию и как оно подвергается. Вещи, которые будут часто меняться и нарушать другие классы, должны быть тщательно рассмотрены, прежде чем разоблачать. Хорошая инкапсуляция означает скрытие вещей, которые, как ожидается, часто меняются, чтобы не нарушать другие классы.