Модули идентифицируются константами. 1 sup> Таким образом, разрешение поиска модулей определяется процедурой поиска константных ссылок. По словам "Ruby Programming Language", Дэвид Фланаган и Юкихеро Мацумото, 1-е изд. 2008 (стр. 261-262), поиск констант выполняется в следующем порядке, где mod
- самый внутренний модуль, который включает ссылку на константу:
mod
. [ 1118] mod.ancestors
, в порядке индекса (то есть иерархии наследования). mod
- получатель, а константа, выраженная в виде символа - аргумент, при условии, что метод был определен. Давайте посмотрим, что мы можем узнать, вставив операторы puts Module.nesting.inspect
и puts ancestors
в код.
module Foo
class UserBar
puts "nesting for UserBar=#{Module.nesting.inspect}"
puts "#{self}.ancestors=#{ancestors}"
end
end
# nesting for UserBar=[Foo::UserBar, Foo]
# Foo::UserBar.ancestors=[Foo::UserBar, Object, Kernel,
# BasicObject]
module Foo
class SubUserBar < UserBar
puts "nesting for SubUserBar=#{Module.nesting.inspect}"
puts "#{self}.ancestors=#{ancestors}"
end
end
# nesting for SubUserBar=[Foo::SubUserBar, Foo]
# Foo::SubUserBar.ancestors=[Foo::SubUserBar,
# Foo::UserBar, Object, Kernel, BasicObject]
module Foo
module Bar
class User
puts "nesting for User=#{Module.nesting.inspect}"
puts "#{self}.ancestors=#{ancestors}"
end
end
end
# nesting for User=[Foo::Bar::User, Foo::Bar, Foo]
# Foo::Bar::User.ancestors=[Foo::Bar::User, Object, Kernel,
# BasicObject]
module Foo
module Bar
class SubUser < User
puts "nesting for SubBar=#{Module.nesting.inspect}"
puts "#{self}.ancestors=#{ancestors}"
end
end
end
# nesting for SubBar=[Foo::Bar::SubUser, Foo::Bar, Foo]
# Foo::Bar::SubUser.ancestors=[Foo::Bar::SubUser,
# Foo::Bar::User, Object, Kernel, BasicObject]
Это говорит нам о том, что если существует класс User
, который не содержится в Foo
(как в Rails), этот класс будет предмет ссылок на User
в классах Foo::UserBar
и Foo::SubUserBar
, но не в Foo::Bar::User
или Foo::Bar::SubUser
. Это понимание должно помочь в организации модулей, чтобы избежать проблем с пространством имен.
1 Так как классы являются модулями, всякий раз, когда я ссылаюсь на «модуль» ниже, я имею в виду классы, а также модули, которые не являются классами. Sup>
Мой голос был бы для codeToName
в данном случае, и я предполагаю, что это делает вывод. Но это вовсе не значит то, что это - имя, я выбрал бы меня во всех случаях; это во многом зависит от объема, дальнейшей инкапсуляции, и так далее. Но похоже на хорошее имя, которое должно помочь сделать Ваш код читаемым:
String country = codeToName["SV"];
Выглядит довольно хорошим, должно быть легко понятным любым. Возможно измените слово "код" на что-то более точное ("код страны" был бы моим следующим выбором).
country_name = countries_by_code[country_code]
Это проходит “телефонную диктовку” тест и также больше походит на естественный язык.
Мне нравится использовать множественные числа для наборов.
countryNames
Править: countryCodes
является неправильным, потому что Вы отображаетесь от кода до имени.
В C# я назвал бы тип, который делает это CountryCodeToNameMapping
. Обычно я называл бы переменную countryCodeToNameMapping
, но в определенных очень ограниченных контекстах (например, лямбды), я, вероятно, назвал бы его c
или m
.
Я обычно делаю это этот путь:
countryCodeMappingByName
Или если отображение уникально, просто:
countryCodeMapping
Используйте что-то, что звучит правильным при объявлении его. Это также означает, называют Ваши ключевые переменные соответственно. Пример:
countryName = countries[countryCode];
Это имеет смысл - Вы даете countries
a countryCode
, и это возвращает a countryName
. Это было бы избыточно:
countryName = countryCodesToNames[countryCode];
Другое голосование за просто pluralizing, на что Вы отображаетесь.
например. country = countries[code]