Изменения

Перевод кусочка оригинального гайда по DM " Гибкость в выборе источника". Не претендую на полную точность перевода.
Строка 315: Строка 315:  
В этом примере для достижения цели используются два аргумента. Первый - это цель сообщения. Второй - текст, который нужно передать.
 
В этом примере для достижения цели используются два аргумента. Первый - это цель сообщения. Второй - текст, который нужно передать.
   −
== Flexibility in Choice of the Source ==
+
== Гибкость в выборе источника ==
   −
If you are paying close attention, a thought may have occurred to you. Couldn't these verbs that take an object as an argument be written using that object as the source rather than an argument? The answer is yes. For example, wink could be rewritten like this:
+
Если вы внимательно следите за этим, то, возможно, вам пришла в голову мысль. Не могут ли эти verb, которые принимают объект в качестве аргумента, быть написаны с использованием этого объекта в качестве источника, а не аргумента? Ответ - да. Например, ''verb/wink'' можно переписать следующим образом:
    
  mob/verb/wink()
 
  mob/verb/wink()
Строка 323: Строка 323:  
     view() << "[usr] winks at [src]."
 
     view() << "[usr] winks at [src]."
   −
Instead of taking a mob as an argument, this verb defines a public verb on mobs that is accessible to others in view, allowing them to wink at the mob. From the user's point of view, these two cases are identical. From the programmer's view, however, it is sometimes more convenient to use one technique over the other.
+
Вместо того чтобы принимать моба в качестве аргумента, этот ''verb'' определяет публичный ''verb'' на мобах, который доступен другим людям, находящимся в поле зрения, и позволяет им подмигнуть мобу. С точки зрения пользователя, эти два случая идентичны. Однако с точки зрения программиста иногда удобнее использовать одну технику, а не другую.
   −
Suppose you wanted to make a special type of mob that when winked at would reveal a magic word. In that case, the best way to do things would be to have the target of the wink be the source of the verb. Then you can override the wink verb for the special mob type like this:
+
Предположим, вы хотите создать особый тип мобов, которые, если им подмигнуть, откроют волшебное слово. В этом случае лучше всего сделать так, чтобы цель подмигивания была источником ''verb''. Тогда вы сможете переопределить ''verb'' подмигивания для особого типа мобов следующим образом:
    
  mob/guard/wink()
 
  mob/guard/wink()
Строка 331: Строка 331:  
     usr << "[src] whispers, 'drow cigam!'"
 
     usr << "[src] whispers, 'drow cigam!'"
   −
When winked at, the guard mob whispers back the magic word. Notice the line that executes the .. (dot-dot) procedure. That is a special name that corresponds to the previous (inherited) version of a verb (called the parent or super verb). This saved us from having to rewrite the line that generated the wink output. That is what is meant by re-usable code in object-oriented programming. With complicated procedures it can save you a lot of trouble.
+
Когда ему подмигивают, охранник(guard) шепчет в ответ волшебное слово. Обратите внимание на строку, выполняющую процедуру ".." (точка-точка). Это специальное имя, которое соответствует предыдущей (унаследованной) версии ''verb'' (так называемый родительский или супер verb). Это избавило нас от необходимости переписывать строку, генерирующую вывод "wink". Именно это подразумевается под повторно используемым кодом в объектно-ориентированном программировании. В сложных процедурах это может избавить вас от множества проблем.
   −
If, instead, we had used the original version of wink which had the target mob as an argument, we would have had to insert code in the general wink verb to check if the target was a guard and act accordingly. In general, good object-oriented design attempts to confine code that is specific to a particular type of object inside the definition of that object. This was achieved in the above example by making the target the source of the wink verb.
+
Если бы вместо этого мы использовали оригинальную версию "wink", в которой целевой моб был аргументом, нам пришлось бы вставить код в общий ''verb/wink'', чтобы проверить, является ли целевой моб гвардом, и действовать соответствующим образом. В целом, хороший объектно-ориентированный подход позволяет ограничить код, специфичный для определенного типа объекта, рамками определения этого объекта. В приведенном выше примере это было достигнуто за счет того, что цель стала источником глагола подмигивания.
   −
In a different situation, the reverse might be the best strategy. For example, you might want a special mob who kills people by winking at them. (If looks could kill...)
+
В другой ситуации лучшей стратегией может оказаться обратная. Например, вам может понадобиться особый моб, который убивает людей, подмигивая им. (Если бы взгляды могли убивать...)
    
  mob/DM/wink(M as mob)
 
  mob/DM/wink(M as mob)
Строка 342: Строка 342:  
     del M  //poof!
 
     del M  //poof!
   −
To do the nasty deed, we used the del instruction, which deletes an object. In this case, we have assumed the existence of the first definition of wink() which takes a mob argument. By organizing things this way, we were able to isolate the special code to the object it applied to, in this case the DM.
+
Чтобы сделать это неприятное дело, мы использовали инструкцию ''del'', которая удаляет объект. В данном случае мы предположили существование первого определения wink(), которое принимает аргумент mob. Организовав все таким образом, мы смогли изолировать специальный код от объекта, к которому он применялся, в данном случае DM.
   −
Of course you might have even more complicated scenarios in which you want to do both variations--that is, having code specific to the type of target and the user. It can still be handled without violating good object-oriented design, but you would need some tools I haven't fully described yet. (For example, you could define a second procedure that carries out a mob's response to being winked at and invoke that from within a private wink verb.)
+
Конечно, у вас могут быть еще более сложные сценарии, в которых вы захотите сделать обе вариации - то есть иметь код, специфичный для типа цели и пользователя. С этим можно справиться, не нарушая хорошего объектно-ориентированного подхода, но вам понадобятся некоторые инструменты, которые мы еще не полностью описали. (Например, вы можете определить вторую процедуру, выполняющую реакцию моба на подмигивание, и вызвать ее из частного ''verb/wink'').
   −
However, don't get too carried away trying to blindly adhere to object-oriented or any other philosophy of code design. At the root of all such theories is the basic and more important principle of keeping things simple. The simpler things are, the less likely you are to make mistakes and the easier it is to fix the errors you do make.
+
Однако не стоит слишком увлекаться, пытаясь слепо следовать объектно-ориентированной или любой другой философии проектирования кода. В основе всех подобных теорий лежит основной и более важный принцип - сохранять простоту. Чем проще все, тем меньше вероятность ошибок и тем легче их исправить!!!
   −
The reason the object-oriented approach tries to confine code about an object to that object is ultimately just organizational. When you want to change the magic word spoken by the guard, you know where to go in the code to do it. And more importantly, if you want to change the guard to an elf, you don't have to remember to also go and modify the wink verb to make elves speak the magic word rather than guards--a seemingly unrelated task.
+
Причина, по которой объектно-ориентированный подход пытается ограничить код об объекте этим объектом, в конечном счете просто организационная. Когда вы хотите изменить волшебное слово, произнесенное охранником, вы знаете, куда идти в коде, чтобы сделать это. И что еще более важно, если вы захотите заменить охранника на эльфа, вам не придется вспоминать, что нужно еще и модифицировать ''verb/wink'', чтобы волшебное слово произносили эльфы, а не охранники, - задача, казалось бы, не имеющая отношения к делу.
   −
But such possibilities are hypothetical and should not take precedence over your own knowledge about what future developments are actually probable. In some situations, the simplest structure might be to confine all code having to do with winking to one place--a single wink verb that handles every special case. That would be procedure-oriented programming, an aged methodology (though tried and true). But who cares what the theory is. Get the job done with clear, concise code. That's what matters in the end.
+
Но такие возможности гипотетичны и не должны превалировать над вашими собственными знаниями о том, какое развитие событий действительно вероятно. В некоторых ситуациях самой простой структурой может быть ограничение всего кода, имеющего отношение к подмигиванию, одним местом - единственным ''verb'' подмигивания, который обрабатывает все особые случаи. Это было бы процедурно-ориентированное программирование, устаревшая методология (хотя и проверенная и верная). Но кого волнует теория. Выполняйте работу с помощью четкого, лаконичного кода. Это то, что в конечном итоге имеет значение.
 
  −
(Of course every true programmer knows that there is no such thing as an end. At best there is a level of completeness that one approaches asymptotically. At worst ... well, never mind the worst, those dark skeletons, cadaverous parasitic programs that suck at the soul until one yields again, hammering out another thousand lines of tangled spaghetti code, writhing like a nest of tapeworms, and long sleepless nights turn into weeks, years, and still no sign of completion! Or so I am told. Being one of the cheery daytime programmers, in bed before midnight and up to milk at dawn, I wouldn't know whether such horror stories are true. If it happens to you, I can give a few pointers on keeping a cow.)
      +
(Конечно, каждый настоящий программист знает, что конца не существует. В лучшем случае есть уровень полноты, к которому человек приближается асимптотически. В худшем... ну, неважно, в худшем, эти темные скелеты, трупные программы-паразиты, которые высасывают душу, пока человек снова не сдастся, набивая очередную тысячу строк запутанного спагетти-кода, извивающегося, как гнездо ленточных червей, и долгие бессонные ночи превращаются в недели, годы, а признаков завершения все еще нет! Так мне сказали. Будучи одним из веселых дневных программистов, ложащихся спать до полуночи и встающих на рассвете, я не знаю, правдивы ли такие истории ужасов. Если это случится с вами, я могу дать несколько советов по содержанию коровы).
    
== A Choice of Arguments ==
 
== A Choice of Arguments ==
33

правки