| Russian | English |
| если ни одна кнопка не нажата, электродвигатель должен быть включен или выключен в зависимости от того, в каком состоянии он находился до этого | with neither button pressed, the motor could be running or stopped depending on what occurred last (см. E.A. Parr Programmable Controllers – An Engineer's Guide) |
| к сожалению, структуры зависимостей только сверху вниз не совсем реалистичны. В действительности будут существовать зависимости снизу вверх, но они могут быть сделаны относительно безопасными квалифицированным проектированием и программированием. Желательный результат таков, чтобы более высокие уровни зависели от более низких уровней, в то время как более низкие уровни всё ещё могли бы связываться с более высокими уровнями, но без создания неуместных неуправляемых зависимостей | 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) |
| Пакет может импортировать другие пакеты. это означает, что пакет A или элемент пакета A может обратиться к пакету B или к его элементам. Следовательно, класс принадлежит только одному пакету, но он может быть импортирован в другие пакеты. Импорт представляет зависимость между пакетами и их элементами | A package may have package imports to other packages. This means that package A or element of package A can refer to package B or to its elements. Consequently, a class is owned by only one package but it can be imported to other packages. Imports introduce dependencies between packages and their elements (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| Структурное проектирование – нечто вроде упражнения в управлении зависимостями модулей. Модуль A зависит от модуля B, если изменения в модуле B могут потребовать изменений в модуле A. Важно, чтобы эти зависимости не противоречили брандмауэрам зависимостей Мартин, 2003. В частности, зависимости не должны быть между несоседними уровнями и не должны создавать циклы | Architectural design is an exercise in managing module dependencies. Module A depends on module B if changes to module B may necessitate changes to module A. It is important that dependencies do not cross dependency firewalls Martin, 2003. In particular, dependencies should not propagate across non-neighboring layers and must not create cycles (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering ssn) |
| Уровень 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) |
