| Russian | English |
| иерархический принцип обмена | send-hierarchy (ssn) |
| иерархический принцип обмена | send hierarchy (принятая в QNX/Neutrino концепция, в силу которой отправляемые сообщения передаются в одном направлении, а ответы на сообщения – в другом. Основной целью реализации иерархического принципа обмена является необходимость исключения состояния взаимной блокировки потоков. Иерархический принцип реализуется назначением клиентам и серверам "уровней иерархии" и обеспечения того, чтобы сообщения передавались только на более высокий уровень иерархии. Это исключает ситуации взаимной блокировки, когда два потока посылают сообщения друг другу, потому что такая ситуация нарушила бы принцип – поток не должен отправлять сообщения другому, если тот находится на нижнем уровне иерархии ssn) |
| Иерархический принцип обмена реализуется назначением клиентам и серверам уровней иерархии и обеспечения того, чтобы сообщения передавались только на более высокий уровень иерархии | A send hierarchy is accomplished by assigning clients and servers a level, and ensuring that messages that are being sent go only to a higher level (см. "Getting Started with QNX Neutrino 2. A Guide for Realtime Programmers" by Rob Krten 1996 ssn) |
| комбинаторный принцип сложения | inclusion-exclusion introduced (ssn) |
| модульный принцип конструирования, эксплуатации и испытаний систем | modular approach to system construction, operation and test (Alex_Odeychuk) |
| модульный принцип организации программ | code modularity (ssn) |
| на рис.3 показан основной принцип процесса начального запуска системы с некоторыми упрощениями | Figure 3 shows only the basic principle of the system boot-up-process with some simplifications |
| организационный принцип при разработке и реализации сложного поведения в управляемых событиями программах | organizing principle for designing and implementing complex behavior in event-driven programs (ssn) |
| организующий принцип при разработке управляемых событиями программ | organizing principle for developing event-driven programs (ssn) |
| основной принцип защиты | stance (стратегия построения защитного экрана, в соответствии с которой запрещено все, кроме необходимого или разрешено все, кроме опасного ssn) |
| основной принцип процесса начального запуска системы | basic principle of the system boot-up-process (ssn) |
| принцип анализа снизу вверх | bottom-up method (ssn) |
| принцип архитектуры | architectural principle (ssn) |
| принцип ацикличности зависимостей | acyclic dependency principle (Alex_Odeychuk) |
| принцип бистабильности | bistability principle (ssn) |
| принцип восходящего анализа | bottom-up method (от простых элементов к сложным ssn) |
| принцип восходящего уведомления | upward notification principle (ssn) |
| принцип восходящей разработки | bottom-up method (от простых элементов к сложным ssn) |
| принцип выделения достаточного времени на обработку ошибок | principle of error handling time (ssn) |
| принцип гибкости | principle of flexibility (ssn) |
| принцип Голливуда | Hollywood principle (hellboy81) |
| принцип группировки | principle of grouping (ssn) |
| принцип действия | function principle (dorywhatever) |
| принцип действия | how it works (ssn) |
| принцип доступности | accessibility principle (ssn) |
| принцип доступности | principle of accessibility (ssn) |
| принцип единственной обязанности | SIP (сокр. от "single responsibility principle"; принцип объектно-ориентированного программирования, который гласит, что каждый объект должен иметь одну и только одну обязанность и эта обязанность должна быть полностью инкапсулирована в модуль или класс. Все методы и свойства класса (экземпляра класса) должны быть направлены исключительно на выполнение этой обязанности. Объединение нескольких сущностей, имеющих разные сферы ответственности в одном классе или модуле, считается неудачным проектным решением Alex_Odeychuk) |
| принцип единственной обязанности | single responsibility principle (принцип объектно-ориентированного программирования, который гласит, что каждый объект должен иметь одну и только одну обязанность и эта обязанность должна быть полностью инкапсулирована в модуль или класс. Все методы и свойства класса (экземпляра класса) должны быть направлены исключительно на выполнение этой обязанности. Объединение нескольких сущностей, имеющих разные сферы ответственности в одном классе или модуле, считается неудачным проектным решением. Alex_Odeychuk) |
| принцип единственной ответственности | single-responsibility principle (ssn) |
| принцип замены | substitution principle (напр., см. Liskov Substitution Principle ssn) |
| принцип замены Лисков | Liskov Substitution Principle (сокр. LSP; в объектно-ориентированном программировании является специфичным определением подтипа, предложенным Барбарой Лисков в 1987 году на конференции в основном докладе под названием "Абстракция данных и иерархия". Этот принцип является важнейшим критерием для оценки качества принимаемых решений при построении иерархий наследования ssn) |
| принцип защитного проектирования | principle of defensive design (ssn) |
| принцип и причина | principle and the reason (ssn) |
| принцип избыточности | redundancy principle (ssn) |
| принцип избыточности | principle of redundancy (ssn) |
| принцип изоляции интерфейса | interface segregation principle (утверждает, что правильнее использовать множество специализированных интерфейсов, чем сгруппировывать абсолютно несвязанные между собой методы в один интерфейс Alex_Odeychuk) |
| принцип изоляции интерфейсов | interface segregation (Alex_Odeychuk) |
| принцип именования классов | class naming principle (ssn) |
| принцип инверсии зависимостей | dependency inversion principle (один из принципов объектно-ориентированного проектирования, позволяющих разработчикам исключить недостатки проекта, сформировав наилучший проект на основе имеющегося набора свойств. Соблюдение принципа инверсии зависимостей необходимо для обеспечения заменяемости объектов без правок по всему исходному коду и для ослабления зависимостей в коде. Когда у вас есть класс A, имеющий указатель на класс B, – классы считаются сильно связанными. Для замены класса B на любой другой придётся исправлять код класса A, – что не совсем хорошо. Предлагается вывести интерфейс класса B, назовем его IB, и заменить тип указателя в классе A на IB. Таким образом, зависимость A->B заменилась на A->IB<-B. Теперь можно вместо B использовать любую другую реализацию интерфейса IB ssn) |
| принцип инверсии управления | IoC principle (англ. термин взят из кн.: Shukla A. Building Web Apps with Spring 5 and Angular Alex_Odeychuk) |
| принцип информационной готовности | principle of information availability (ssn) |
| принцип использования пакета знакомств | acquaintance package principle (ssn) |
| принцип исправления ошибок | error correction principle (ssn) |
| принцип исправления ошибок | principle of error correction (ssn) |
| принцип конвертирования кода Грея в двоичный код | principle of converting Gray into binary (ssn) |
| принцип локальности | locality principle (ssn) |
| принцип минимально необходимого воздействия | principle of least intrusiveness (англ. термин взят из кн.: Ottinger J.B., Minter D., Linwood J. Beginning Hibernate. – Apress, 2014. – 223 р. Alex_Odeychuk) |
| принцип минимальных обязательств | principle of least commitment (см. Object-Oriented Analysis and Design with Applications 3rd Edition by Grady Booch ssn) |
| принцип многократности использования кода | reuse philosophy (из кн.: Солтер Н.А., Клепер С.Дж. С++ для профессионалов Alex_Odeychuk) |
| принцип многоуровневой архитектуры | principle of layered architecture (ssn) |
| принцип наблюдаемости | visibility principle (ssn) |
| принцип наименьшего удивления | principle of least astonishment (см. Object-Oriented Analysis and Design with Applications 3rd Edition by Grady Booch ssn) |
| принцип наименьших привилегий | principle of least privilege (ssn) |
| принцип необходимого знания | need to know (стратегия защиты информации, соответственно которой пользователь получает доступ только к данным, безусловно необходимым ему для выполнения конкретной функции ssn) |
| принцип нисходящей зависимости | downward dependency principle (ssn) |
| принцип оборонительного проектирования | principle of defensive design (ssn) |
| принцип обратной связи | feedback principle (ssn) |
| принцип обратной связи | feedback control approach (ssn) |
| принцип объектно-ориентированного программирования | object-oriented programming principle (Alex_Odeychuk) |
| принцип объектно-ориентированного проектирования | principle of OOD (ssn) |
| принцип ООП | principle of OOD (ssn) |
| принцип определения | detection principle (напр., направления вращения ssn) |
| принцип определения направления вращения | detection principle for direction of rotation (ssn) |
| принцип организации инфраструктуры | infrastructure principle (ssn) |
| принцип отделения интерфейса | interface segregation principle (один из принципов объектно-ориентированного проектирования, позволяющих разработчикам исключить недостатки проекта, сформировав наилучший проект на основе имеющегося набора свойств ssn) |
| принцип отделения интерфейса | ISP (сокр. от "interface segregation principle" Alex_Odeychuk) |
| принцип открытия-закрытия | Open Closed Principle (один из принципов объектно-ориентированного проектирования, позволяющих разработчикам исключить недостатки проекта, сформировав наилучший проект на основе имеющегося набора свойств ssn) |
| принцип открытости / закрытости | Open Closed Principle |
| принцип открытости-закрытости | OCP (сокр. от "open-closed principle"; This principle states that the classes are open for extension, but closed for modification. Based on this principle, the core classes of any framework consist of some methods which are marked as final in Java, which, essentially, means that these final methods can not be overridden with custom behavior. Alex_Odeychuk) |
| принцип открытых систем | open systems principle (ssn) |
| принцип отражения | reflection principle |
| принцип повторного использования | reuse principle (ssn) |
| принцип подстановки | substitution principle (ssn) |
| принцип подстановки Лисков | LSP (сокр. от "Liskov substitution principle"; This principle states that if a class A (child class) is derived from class B (parent class), then the object of class B can be replaced by (or substituted with) an object of class A without changing any of the properties of class B. It can be inferred that the functions which use references of the base class must be able to use objects of the derived class without the need to know about the implementation of the base class. Alex_Odeychuk) |
| принцип подстановки Лисков | Liskov Substitution Principle (ssn) |
| принцип подстановочности | substitutability principle (принцип, согласно которому любой экземпляр потомка X может использоваться в качестве фактического значения переменной или параметра, объявленного как X, не нарушая при этом семантику объявления или использования. Другими словами, экземпляр элемента-потомка можно подставить вместо экземпляра элемента-предка (термин Барбары Лисков (Barbara Liskov)) ssn) |
| принцип понижения сложности | principle of complexity (ssn) |
| принцип построения памяти | memory architecture (ssn) |
| принцип преобразования кода Грея в двоичный код | principle of converting Gray into binary (ssn) |
| принцип программирования | programming paradigm (ssn) |
| принцип проектирования с защитой | principle of defensive design (ssn) |
| принцип простоты | YAGNI (сокр. от "You Ain't Gonna Need It" | принцип проектирования программного обеспечения, предусматривающий, что необходимо реализовывать только требуемые заказчиком функциональные возможности приложения и что реализация должна быть настолько простой, насколько это возможно. В коде надо определять только те классы, интерфейсы и их члены, которые нужны для выполнения заявки. Проще добавить функциональность в код, чем удалять из класса почти всё. Alex_Odeychuk) |
| принцип простоты | simplicity principle (ssn) |
| принцип работы | basic idea (ssn) |
| принцип равноправия | equal-partner contention (ssn) |
| принцип разделения интерфейсов | interface separation principle (Alex_Odeychuk) |
| принцип разделения обязанностей | separation of concerns principle (англ. термин взят из кн.: De Sanctis V. ASP.NET Core and Angular 2 Alex_Odeychuk) |
| принцип разделения обязанностей | single responsibility principle (каждый объект в программе должен иметь единственную обязанность. Если объект выполняет множество различных обязанностей – его необходимо разделить. Например, объект печати отчётов ответственен за формат и за содержимое отчётов – это неправильно. За формат должен отвечать один объект, за содержимое – другой Alex_Odeychuk) |
| принцип разделения обязанностей | SoC principle (сокр. от "separation of concerns principle" Alex_Odeychuk) |
| принцип разделения обязанностей в коде | principle of separation of concerns within code (Alex_Odeychuk) |
| принцип распределения функций | principle of function allocation (ssn) |
| принцип расширенной проекции | extended projection principle (ssn) |
| принцип регулярности | regularity principle (принцип регулярности требует соблюдения единообразия при проектировании отдельных модулей системы ssn) |
| принцип рекурсивного разбиения | principle of recursive decomposition (MichaelBurov) |
| принцип рекурсивного разбиения | principle of recursively decomposing (ssn) |
| принцип рекурсивного разбиения большой задачи на меньшие | principle of recursively decomposing a large problem into one or more smaller ones (ssn) |
| принцип рекурсивной декомпозиции | principle of recursive decomposition (MichaelBurov) |
| принцип рекурсивной декомпозиции | principle of recursively decomposing (MichaelBurov) |
| принцип самодокументирования | self-documentation principle (ssn) |
| принцип согласованности | consistency principle (ssn) |
| принцип согласованности | principle of consistency (ssn) |
| принцип сокрытия | the hiding principle (ssn) |
| принцип соответствия обучению | principle of compatibility with learning (ssn) |
| принцип соответствия практике | principle of compatibility with practice (ssn) |
| принцип соседней связи | neighbor communication principle (ssn) |
| принцип справедливости | justice concept (ssn) |
| принцип толерантности | tolerance principle (ssn) |
| принцип унифицированного доступа | uniform access principle (ssn) |
| принцип управления из одной точки | principle of single-point control (ssn) |
| принцип устранения циклов | cycle elimination principle (ssn) |
| принцип хранения | storage concept (ssn) |
| принцип "что видишь, то и получаешь" | what you see is what you get (ssn) |
| принцип Чёрча-Тьюринга | Church-Turing principle (ssn) |
| принцип явной ассоциации | explicit association principle (ssn) |
| ролевой принцип организации проектирования | role-based design (настройка системы проектирования и её функций на конкретные особенности пользовательской задачи ssn) |
| соблюдать принцип единственной обязанности | adhere to the single responsibility principle (принцип единственной обязанности – это принцип объектно-ориентированного программирования, который гласит, что каждый объект должен иметь одну и только одну обязанность и эта обязанность должна быть полностью инкапсулирована в модуль или класс. Все методы и свойства класса (экземпляра класса) должны быть направлены исключительно на выполнение этой обязанности. Объединение нескольких сущностей, имеющих разные сферы ответственности в одном классе или модуле, считается неудачным проектным решением. Если класс выполняет множество различных обязанностей – его необходимо разделить. Например, класс печати отчётов ответственен за формат и за содержимое отчётов – это неправильно. За формат должен отвечать один класс, за содержимое – другой Alex_Odeychuk) |
| соблюдать принцип единственной ответственности | adhere to the single responsibility principle (Alex_Odeychuk) |
| соблюдать принцип единственной ответственности | uphold the single responsibility principle (Alex_Odeychuk) |
| Уровень 2 на рис. 9.4 стабилен, а Уровень 1 нестабилен. Уровень 1 зависит от Уровня 2. Уровень 2 независим и поэтому может быть заменен новым без "эффекта ряби" в остальной части системы. это – принцип и причина, стоящие за разрешением сильной зависимости сильной связи в нисходящем направлении и обеспечением слабой зависимости слабой связи в восходящем направлении | Layer 2 in Figure 9-4 is stable and Layer 1 is instable. Layer 1 depends on Layer 2. Layer 2 is independent and can therefore be replaced by a new one without a ripple-effect on the rest of the system. This is the principle and the reason behind allowing a high dependency high coupling in the top-down direction and ensuring a low dependency low coupling in the bottom-up direction (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
