О словаре | FAQ | Вход | Регистрация |Настройки
Словарь Мультитран
Dicts Forum Buy Download Guestbook Contacts в тестовом режиме открыт новый сайт Мультитрана
   Eng 
 Термины по тематике Программирование, содержащие знать: все формы слова (11) | только заданная форма слова (7)
 аварийные сигналы должны сообщать операторам только то, что им необходимо знатьalarms should only tell the operators what they need to know (ssn)
 В результате организация будет знать, с чего начинать и как привести инициативы SOA в соответствие с бизнес-требованиями и приоритетамиThis is how an organization might know where to start and align its SOA initiatives with business needs and priorities (ssn)
 "Жизнь, какой мы её знаем"Live-As-We-know-it (см. artificial life ssn)
 знать все возможные значенияknow all possible values (Alex_Odeychuk)
 знать, с чего начинатьknow where to start (ssn)
 знать текущее состояние проектаbe familiar with the current state of the project (Alex_Odeychuk)
 мочь и не знатьmight not know (ssn)
 Мы знаем, что современные компьютеры работают очень быстро и обладают почти невероятными способностями в области решения задачWe know that today's computers are extremely fast and often seem to have magical solution properties (ssn)
 Последствие делегирования таково, что клиент может и не знать своего реального поставщика и он даже может не хотеть знать это, пока не получит "требуемое" . В отличие от рис. 9.7 знание реального поставщика может быть недоступно из статического анализа программного кода и может быть скрыто за динамикой наследования в частности, наследования интерфейса и полиморфизмаThe consequence of delegation is that a client might not know its real supplier and it might not even care to know as long as the “goods” are supplied . Unlike in Figure 9-7, the knowledge of the real supplier may not be available from a static analysis of the program code and be hidden behind the dynamicity of inheritance in particular interface inheritance and polymorphism (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Сделать зависимости методов статически видимыми в коде посредством явных ассоциаций между классами Ц настоятельно рекомендуемая практика [Ли и Тепфенхарт, 2002]. Это важно, потому что зависимости методов часто не поддаются обнаружению при анализе исходного кода. В случае наследования или полиморфизма и по требованиям уровневой структуры формирователь сообщения [объект-клиент] часто не знает конкретного получателя сообщения [объект-поставщик] до времени выполненияMaking method dependencies statically visible in the code by means of explicit associations between classes is a strongly recommended practice [Lee and Tepfenhart, 2002]. This is important because method dependencies are frequently not discoverable from the analysis of the source code. In the presence of inheritance and polymorphism and because of the demands of the layered architecture, a message originator [client object] frequently does not know the specific receiver of the message [supplier object] until runtime (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Структурщики знают, что хорошую структуру удаётся создать не сразу — она должна развиваться по мере накопления опыта. Им также известно, что чаще приходится читать и модифицировать код, а не писать новый. В основе поддержки читаемости и модифицируемости кода лежит рефакторинг — как в частном случае структур, так и для программного обеспечения в целомFrameworkers know that a framework won't be right the first time around — it must evolve as they gain experience. They also know that the code will be read and modified more frequently than it will be written. The key to keeping code readable and modifiable is refactoring — for frameworks, in particular, but also for software in general (см. Refactoring: Improving the Design of Existing Code by Martin Fowler et al. (1999) ssn)
     
 Оценить сайт