Помогите немного с английским

stalxed

Новичок
У меня есть знакомые люди, кто помогает с английским.
Но в паре моментов они оказались бессильны.
Помогите пожалуйста!
1) Замечаю часто, в различных проектах, везде используются для слова удалить remove и delete без какой-либо логики.
В плане кода, как лучше перевести:
  • удалить элемент из коллекции
  • удалить файл(директорию)
  • удалить запись в БД
  • удалить сущность
?
2) В ступор вводит следующий фрагмент из книги Эванса про фабрики, отложил его, пошёл читать дальше, но мучает как-то он меня:
  • All of the attributes of the object are available to the client, so that no object creation gets nested inside the constructor exposed to the client.
Здесь описывается один из случаев, когда нужно использовать конструктор, а не фабрику.
Переводчик русского издания какую-то ересь написал, да и английский вариант мне не понятен, хотя все слова знаю и гугл транслейтер фигню даёт...
 

AnrDaemon

Продвинутый новичок
Сама фраза конечно завёрнута… и противоречива. Начало понятно, а вот конец вызывает одну головную боль.
"Все аттрибуты объекта доступны клиенту, так что никакие [элементы? детали? тут явно пропущено слово] создания объекта…" а вот дальше начинается дурдом. "gets nested inside the constructor" можно перевести как "скрытые (или скрываемые) в конструкторе", но отрицание ломает логику фразы при переводе "exposed to client" - "[не?]отображаются клиенту."
Как говаривала мой преподаватель по технологии программирования - "ещё раз такое напишешь - заставлю писать "Hello world" 10 различными способами."
 

С.

Продвинутый новичок
Вообще-то "nested" ่это "вложенный", а не "скрытый". Так что логика не страдает.

Delete and remove are defined quite similarly, but the main difference between them is that delete means erase (i.e. rendered nonexistent or nonrecoverable), while remove connotes take away and set aside (but kept in existence).
Хотя в общеупотребляемом IT-контексте описанная филологическая разница между remove и delete отсутствует. Так что их можно считать полными синонимами..
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
2) В ступор вводит следующий фрагмент из книги Эванса про фабрики, отложил его, пошёл читать дальше, но мучает как-то он меня:
  • All of the attributes of the object are available to the client, so that no object creation gets nested inside the constructor exposed to the client.
Без контекста не понял, пришлось открыть Эванса. Тут явно имеется ввиду Value Object. :) Ну или подобные случаи, когда фактически классом изображена структура, возможно, с хелпер-методами, которые просто оперируют публичными же (не важно, напрямую или через геттеры-сеттеры) атрибутами.
 

fixxxer

К.О.
Партнер клуба
Чтобы такого не происходило, хотя эванс писал до того как эвенты стали мейнстримом... Но общий принцип и проблема те же. http://ddd.io/2015/01/19/event-sourced-child-entities-in-broadway/
Задумался - а ведь это получается фактически smalltalk, к которому добавили этакий broadcast всего лишь. Ну и сообщение стало не литералом, а объектом.
 

stalxed

Новичок
Delete and remove are defined quite similarly, but the main difference between them is that delete means erase (i.e. rendered nonexistent or nonrecoverable), while remove connotes take away and set aside (but kept in existence)
Т.е. получается верно так?
  • Delete entry in the database.
  • Delete file.
  • Remove item from the collection.

Без контекста не понял, пришлось открыть Эванса. Тут явно имеется ввиду Value Object. :) Ну или подобные случаи, когда фактически классом изображена структура, возможно, с хелпер-методами, которые просто оперируют публичными же (не важно, напрямую или через геттеры-сеттеры) атрибутами.
Да, я тоже так думаю, что имеется в виду некоторая структура, в которой все атрибуты можно менять. Но это скорее entity, так как value object должны быть immutable.

All of the attributes of the object are available to the client, so that no object creation gets nested inside the constructor exposed to the client.
Перевод с учетом этого:
Все атрибуты объекта доступны для клиента, так что все операции создания внутри конструктора открыты для клиента.
Но не уверен :)

Чтобы такого не происходило, хотя эванс писал до того как эвенты стали мейнстримом... Но общий принцип и проблема те же. http://ddd.io/2015/01/19/event-sourced-child-entities-in-broadway/
Ну к теме это не имеет отношения, или как-то связано с тем загадочным предложением? Не вкурю)
Я тут реализовываю application layer при помощи команд, как здесь https://github.com/qandidate-labs/broadway/tree/master/src/Broadway/CommandHandling
Если честно, бесит обилие команд. Но application layer имеет не такой уж детализированный API, как объекты в domain layer, поэтому использование тут
http://ddd.io/2015/01/19/event-sourced-child-entities-in-broadway/
На каждый чих объекта event это ужас. Имхо, но может быть применимо только для сложных агрегатов.
И то.... по мне передача данных аргументами намного читабельнее. Так как когда видишь объект Event - нужно его открыть, чтобы увидеть список входящих аргументов(это уже не говоря о том, что его нужно создать, редактировать, не забыть удалить, когда он исчезнет в агрегате, etc).
В чём профит?
P.S.: изучаю DDD не спеша, и Event Sourced плотно не изучал, и не юзал.
 

С.

Продвинутый новичок
Т.е. получается верно так?
  • Delete entry in the database.
  • Delete file.
  • Remove item from the collection.
Можешь придерживаться такого высокого штиля. Но жизнь показывает, что мало кто из IT следует этому правилу и поэтому термины взаимозаменяемы без ущерба для смысла. Вспомним хотябы UNIX-команду rm.
 

fixxxer

К.О.
Партнер клуба
Да, я тоже так думаю, что имеется в виду некоторая структура, в которой все атрибуты можно менять. Но это скорее entity, так как value object должны быть immutable.
Мне кажется, и то, и другое. Не заметил требования менять. Available может быть и to read. :)

Но правильно перевести не возьмусь, чото в этой фразе Эванс сам себя перемудрил, похоже.
 
Сверху