О словаре | FAQ | Вход | Регистрация |Настройки
Словарь Мультитран
Dicts Forum Buy Download Guestbook Contacts в тестовом режиме открыт новый сайт Мультитрана
   Eng 
 Термины по тематике Программирование, содержащие quite: все формы слова (21)
 as is quite commonкак это обычно бывает (ssn)
 Because state space models are described by a set of first order differential equations, it is quite easy to solve themПоскольку модели пространства состояний описываются системой дифференциальных уравнений первого порядка, их относительно легко решить (см. Control system design by Graham C. Goodwin et al. (2000) ssn)
 Figure 15-3 represents design refactored by using Extract Class and Extract Interface on the presentation layer. Refactoring of this layer has limited value for Iteration 2. The move in Iteration 2 to graphical user interface signifies quite radical re-organization of the presentation layer. Even so, the existence of interface and new classes will facilitate the transition. In some way, more radical refactoring would be justified. For example, POutMsgBodyBuilder can be split into two classes to separate displaying of outmessage from preparing it for emailingРис. 15.3 представляет улучшенный проект, используя Класс извлечения и Интерфейс извлечения на уровне представления. Рефакторинг этого уровня для итерации 2 имеет ограниченный объём. Переход в итерации 2 к графическому пользовательскому интерфейсу означает весьма радикальную реорганизацию уровня представления. Даже в рассматриваемом случае наличие интерфейса и новых классов облегчит этот переход. В некоторых случаях был бы оправдан более радикальный рефакторинг. Например, класс POutMsgBodyBuilder может быть разбит на два класса, чтобы отделить отображение исходящего сообщения от подготовки его для передачи по электронной почте (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Figure 15-1 shows how the Extract Class refactoring could be applied to the CActioner class Section 13.4.1 . CActioner is involved in two quite disparate tasks: in retrieving outmessages requested by the user and in sending emailing outmessages. It is logical to extract these two tasks into separate classes: CMsgSeeker and CMsgSender. To avoid terminological confusion, CActioner is renamed to CAdmin. Constructor and non-public methods are not consideredРис. 15.1 показывает, как рефакторинг Класс извлечения мог бы быть использован для класса CActioner раздел 13.4.1 . Класс CActioner включен в две совершенно несопоставимые задачи: извлечение исходящих сообщений, требуемых пользователем, и посылка исходящих сообщений передача по электронной почте . Логично извлечь эти две задачи в отдельные классы: CMsgSeeker и CMsgSender. Чтобы избежать терминологического беспорядка, CActioner переименован в CAdmin. Конструктор и методы, не являющиеся общедоступными, не рассматриваются (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 If, as is quite common, there are ten interlock signals which allow a motor to start, the maintenance staff will need to be able to check these quickly in the event of a faultЕсли, как это обычно бывает, имеется порядка десяти блокирующих друг друга сигналов, позволяющих запустить электродвигатель, обслуживающий персонал в случае неисправности должен быть способен быстро проверить все эти сигналы (см. E.A. Parr Programmable Controllers - An Engineer's Guide ssn)
 quite different situationsсовершенно разные ситуации (ssn)
 quite disparate tasksсовершенно несопоставимые задачи (ssn)
 quite disparateсовершенно несопоставимый (ssn)
 quite dramaticвесьма впечатляющий (ssn)
 quite primitive text-based user interfaceвесьма примитивный текстовый пользовательский интерфейс (ssn)
 quite primitiveвесьма примитивный (ssn)
 quite quicklyочень быстро (ssn)
 quite radical re-organizationвесьма радикальная реорганизация (ssn)
 quite radicalвесьма радикальный (ssn)
 Refactoring methods or simply refactorings are basic principles and best practices of changing the code to improve its understandability, maintainability and scalability. The code changes are small, one step at a time, but the improvements can be quite dramatic. Unfortunately, so can be deteriorations of code, if refactorings are not done properlyМетоды рефакторинга или просто рефакторинги – основные принципы и лучшая практика изменения кода с целью улучшения его понятности, сопровождаемости и масштабируемости. Изменения кода небольшие, по одному шагу, но усовершенствования могут быть весьма впечатляющими. К сожалению, можно также и ухудшить код, если рефакторинги сделаны не должным образом (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Refactoring patterns position the system for easy scalability when it grows to a large-scale solution. Iteration 1 of the EM case-study emphasizes the database presence in the application while retaining quite primitive text-based user interface. Iteration 2 makes a move to a graphical user interface. Refactoring patterns discussed in this chapter apply still to Iteration 1 and, therefore, concentrate on other than user interface issuesПаттерны рефакторинга обеспечивают системе более лёгкую масштабируемость, когда она перерастает в крупномасштабное решение. Итерация 1 учебного примера EM подчёркивает присутствие БД в приложении при сохранении весьма примитивного текстового пользовательского интерфейса. Итерация 2 делает шаг к графическому пользовательскому интерфейсу. Паттерны рефакторинга, рассматриваемые в данной главе, все ещё применяются к итерации 1 и поэтому концентрируются на проблемах, отличных от проблем пользовательского интерфейса (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 The primary reason for this distinction between the nature of tasks and states is that sequential activity is a part of many mechanical systems. Even for systems that do not seem to be fundamentally sequential, such as process or web systems, the sequential breakdown within task seems to work quite well. During normal operation, tasks tend to stay in only one or two statesОсновная причина для этого различия между природой задач и состояний-то, что последовательная деятельность характерна для многих механических систем. Даже для систем, которые не кажутся сугубо последовательными, например, процесс или системы изготовления ткани, последовательное разбиение в пределах задачи, кажется, работает весьма хорошо. В течение нормального функционирования, задачи имеют тенденцию оставаться только в одном из двух состояний (см. Auslander David M. Mechatronics: A Design and Implementation Methodology for Real Time Control Software ssn)
 This approach is quite useful because there is a correlation between the response of a system to a standard test input and the system's ability to perform under normal operating conditionsТакой подход вполне оправдан, т.к. имеется корреляция между реакцией системы на типовой входной сигнал и её поведением в реальных рабочих условиях (см. Modern Control Systems by Richard C. Dorf & Robert H. Bishop (2008) ssn)
 to work quite wellработать весьма хорошо (ssn)
 two quite disparate tasksдве совершенно несопоставимые задачи (ssn)
 Unfortunately, the top-down only dependency structure is not quite realistic. In reality, the bottom-up dependencies will exist, but they can be made relatively harmless by skilful design and programming. A desired outcome is that higher layers depend on lower layers while lower layers can still communicate with higher layers without exerting undue unmanageable dependenciesК сожалению, структуры зависимостей только сверху вниз не совсем реалистичны. В действительности будут существовать зависимости снизу вверх, но они могут быть сделаны относительно безопасными квалифицированным проектированием и программированием. Желательный результат таков, чтобы более высокие уровни зависели от более низких уровней, в то время как более низкие уровни все ещё могли бы связываться с более высокими уровнями, но без создания неуместных неуправляемых зависимостей (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
     
 Оценить сайт