| English | Russian |
| as expected by the Extract Class refactoring, CAdmin maintains association links to new classes. The links are supported by two methods: getMsgSeeker and getMsgSender. The former gets the CMsgSeeker object, the one responsible for retrieving outmessages for presentation layer. The latter gets the CMsgSender object responsible for emailing outmessages | как ожидается, с помощью рефакторинга Класс извлечения CAdmin обеспечивает связи ассоциации с новыми классами. Связи поддерживаются двумя методами: getMsgSeeker и getMsgSender . Первый получает объект CMsgSeeker, который отвечает за извлечение исходящих сообщений для уровня представления. Второй получает объект CMsgSender, ответственный за исходящие сообщения, передаваемые по электрон почте (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| these observations are particularly, and painfully, true for modern object-oriented software production. The object paradigm equips a software engineer with a multitude of very powerful programming abstractions, which – when used unwisely – result in programs impossible to understand and maintain, even by programmers who wrote them | эти утверждения, особенно и в большой степени, истинны для современного объектно-ориентированного создания ПО. Понятие объекта вооружает инженера ПО множеством очень мощных абстракций программирования. Но если они используются неблагоразумно, получаются программы, которые невозможно ни понять, ни обслуживать даже теми программистами, которые написали их (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| these observations are particularly, and painfully, true for modern object-oriented software production. The object paradigm equips a software engineer with a multitude of very powerful programming abstractions, which when used unwisely result in programs impossible to understand and maintain, even by programmers who wrote them | эти утверждения, особенно и в большой степени, истинны для современного объектно-ориентированного создания ПО. Понятие объекта вооружает инженера ПО множеством очень мощных абстракций программирования. Но если они используются неблагоразумно, получаются программы, которые невозможно ни понять, ни обслуживать даже теми программистами, которые написали их (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
