Не пытайтесь «перевести». Просто расскажите своими словами, по-русски, но максимально близко к иностранному тексту.
Но для этого нужно знать язык, на который переводишь. Вы его не забыли после тесного общения с зарубежными источниками?
Достижения в области machine learning не в малой степени
должна переводится как «трансферное усвоение»
Может лучше так:
Достижения в области machine learning в немалой степени
должна переводиться как «трансферное усвоение»
Хорошо, пусть у нас есть две процедуры, которые построены аналогично ОченьПолезныйИВажныйКод. Процедура ИзменитьОкладыСотрудников устанавливает новые оклады в справочнике сотрудников, и все это во вложенной транзакции. Вторая процедура ИзменитьОкладыДолжностей записывает оклады в справочник должностей, тоже во вложенной транзакции. Задача написать обработку Индексация, которая устанавливает новые оклады для сотрудников и их должностей.
Если вызвать эти процедуры последовательно, понадеявшись на их корректность, мы потеряем атомарность. Например, ИзменитьОкладыСотрудников сработает, а ИзменитьОкладыДолжностей – нет. В итоге в справочнике сотрудников будут новые оклады, а в справочнике должностей – старые. Нельзя менять оклады сотрудников, не меняя оклады должностей, и наоборот. Эти данные должны быть согласованы. Поэтому нужно главную процедуру обработки выполнять в транзакции.
А внутренние транзакции не имеют смысла. Зачем в процедуре, которая что-то выполняет и сделана для вызова из других процедур, внутренняя транзакция? Все равно будет более общая транзакция, которая объединит все модификации данных и сделает это согласованно. В итоге получается такой вариант:
Процедура ОченьПолезныйИВажныйКод(СписокСсылокСправочника)
Для Каждого Ссылка Из СписокСсылокСправочника Цикл
ОбъектСправочника = Ссылка.ПолучитьОбъект();
ОбъектСправочника.КакоеТоПоле = "Я изменен из программного кода";
ОбъектСправочника.Записать();
КонецЦикла;
КонецПроцедуры
Список ссылок нужно получать из запроса ДЛЯ ИЗМЕНЕНИЯ.
Во-первых, вложенные они только на уровне синтаксиса. Всегда действует только транзакция самого верхнего уровня.
А во-вторых, во вложенных транзакциях нет никакой необходимости. Атомарность – первое свойство транзакции. Изменения данных инициирует клиентский запрос, который может быть вызван нажатием кнопки в форме, да и вообще любым интерактивным действием, это может быть вызов web-сервиса или запуск платформы из bat-файла с автоматическим выполнением обработки, обращение через COM-соединение и так далее. Во всех этих случаях есть главная процедура, которая обрабатывает клиентский запрос. Именно она и должна начинать и фиксировать транзакцию. С точки зрения пользователя вложенных транзакций нет. Он либо получает атомарно изменения, которые инициировал, либо нет. В этом и заключается атомарность.
Что значит без неявной? Запись объектов выполняется в неявной транзакции. А вот проконтролировать, что внутри транзакции нет вложенных транзакций, может только разработчик. Если он, конечно же, станет придерживаться архитектуры приложения без вложенных транзакций (как явных так и не явных) внутри основной транзакции (явной или неявной).
Изоляция модулей идет в разрез с двумя свойствами транзакции – атомарностью и согласованностью. Между началом и завершением транзакции все изменения данных, в том числе вложенные подоперации, должны быть согласованны.
Имя процедуры не должно быть ОченьПолезныйИВажныйКод. Это четвертая, но самая важная ошибка. Уважаемый автор, с таким именем Вы как бы намекаете на то, что эту процедуру можно расположить где угодно и вызывать из любого места. Вы так яростно сражаетесь с вложенными транзакциями! Остановитесь на минуту. Вложенные транзакции не поддерживаются! Из этого факта нужно сделать один простой вывод: их не нужно допускать на уровне архитектуры приложения.
Сценарий транзакции должен начинать транзакцию и завершать ее, находясь в начале стека выполнения на сервере. Вызов извне будет только из клиентского события. Тогда не нужно оборачивать транзакцию в попытку, так как она откатится естественным образом. И никаких НачатьТранзакцию в глубине стека! Можно вызывать процедуры модификации данных, но они не должны начинать транзакции. Только код обработки клиентского запроса на верхнем уровне знает, когда начинается транзакция – собственно, когда обрабатывается клиентский запрос.
Вы не ответили, как сделать виртуальную функцию, которая рассчитывается по-разному для разных категорий товаров. Характеристики это половина проблемы, нужны алгоритмы обработки этих характеристик. В ООП есть полиморфизм, а как его реализовать здесь?
Расширяемость модели должна быть, не вопрос. Но и структуру хранилищ менять надо, если это необходимо для новой модели. В противном случае, делая неизменной структуру базы данных, вы не сможете оптимально ее использовать, так как для новых типов предметной области могут понадобиться новые индексы, хранимые процедуры и прочее. А делая неизменными программные классы модели, вы не сможете добавить в них код. Модель предметной области это же не только данные, но и алгоритмы их обработки. Какие применения хранилищ, с которыми вы работаете?
Не переписывать, а дополнять и немного изменять, если мы правильно спроектировали иерархию классов и предусмотрели возможность развития и быстрого внесения изменений. Все приложения сейчас обновляются, и это в порядке вещей. «Soft» в отличие от «Hard» мягкий, то есть изменчивый. Бухгалтерский софт обновляется с изменением законодательства, драйвера обновляются с выходом новых устройств, и т.д. Изменения в моделируемой предметной области влекут изменения в приложении, что в этом необычного? И если руки не кривые, можно будет использовать созданные классы в аналогичных проектах.
классификацию не придется пересматривать
Давайте на примере. В классе «Транспортные средства» есть поля «Объем топливного бака, л» и «Расход топлива на 100 км». И мы реализовали функцию расчета, сколько можно проехать на полном баке без дозаправки «Максимальное расстояние» = Объем бака / Расход * 100. Отлично, но появляются летающие автомобили, которым требуется топливо на взлет и посадку. Мы добавляем класс «Летающий автомобиль» и поля «Расход топлива на взлет, л» и «Расход топлива на посадку, л». Если мы предусмотрительно объявили функцию «Максимальное расстояние» как виртуальную, то переопределяем ее: Расход на взлет + Объем бака / Расход * 100 + Расход на посадку. Как это сделать без ООП, если у нас один класс «Товары»?
Поэтому классификация в коде вводится не для того, чтобы разбить товары на группы или выделить какие-то опции. Классы различаются еще и поведением, то есть методами.
Подскажите, а откуда требование к сохранению структуры хранилищ? На мой взгляд, структура данных должна соответствовать модели, которая появилась при разработке классов после анализа предметной области. Если меняется предметная область (изобрели новую модель моторной лодки на подводных крыльях) или наш подход к моделированию (объединяем два хранилища классов в одно), то уместно внести изменения в структуру.
Задача же не в создании классов на все времена. Это попросту невозможно. Если произойдут изменения в предметной области, можно будет внести изменения в классы и выпустить обновление. По-любому придется пересматривать классификацию, когда появятся летающие автомобили.
Мы же выполняем классификацию существующих объектов предметной области, а не всех возможных и невозможных объектов, которые появятся (или не появятся) в будущем. А это лишь небольшое подмножество из произведения множеств значений их свойств. И классифицируя это подмножество, ничего придумывать не нужно, так как обычно люди всему дают названия. Возьмите для примера любую модель транспортного средства.
как теперь вы назовете моделируемый объект? Автомобиль-плавсредство? А, если потом появятся другие классы, к которым относится этот объект? Будете перечислять их названия через дефис, и говорить: автомобиль-плавсредство-альфа-омега?
Зачем что-то выдумывать, чтобы назвать моделируемый объект? Если мы моделируем классы для хранения моделей плавательных средств и классы для хранения моделей автомобилей, то у них уже есть названия – это названия моделей. Например, для глиссирующего автомобиля-амфибии «Тритон» мы выберем имя класса Тритон.
Объекты Вселенной не взаимодействуют все-со-всеми сразу во все времена. Хотя законы действуют на все объекты, каждый из объектов ограничен своим пространством-временем. А забывая ограничить пространство-время фотона, Вы наделяете фотон сверх-возможностями. Чтобы получить пространство фотона, давайте представим срез Вселенной не только через пространство, но и через время. Каждый объект попадет в срез один раз по следующему принципу: чем дальше расстояние до объекта, тем из более позднего будущего он пропадет в срез.
Но для этого нужно знать язык, на который переводишь. Вы его не забыли после тесного общения с зарубежными источниками?
Может лучше так:
Если вызвать эти процедуры последовательно, понадеявшись на их корректность, мы потеряем атомарность. Например, ИзменитьОкладыСотрудников сработает, а ИзменитьОкладыДолжностей – нет. В итоге в справочнике сотрудников будут новые оклады, а в справочнике должностей – старые. Нельзя менять оклады сотрудников, не меняя оклады должностей, и наоборот. Эти данные должны быть согласованы. Поэтому нужно главную процедуру обработки выполнять в транзакции.
А внутренние транзакции не имеют смысла. Зачем в процедуре, которая что-то выполняет и сделана для вызова из других процедур, внутренняя транзакция? Все равно будет более общая транзакция, которая объединит все модификации данных и сделает это согласованно. В итоге получается такой вариант:
Список ссылок нужно получать из запроса ДЛЯ ИЗМЕНЕНИЯ.
А во-вторых, во вложенных транзакциях нет никакой необходимости. Атомарность – первое свойство транзакции. Изменения данных инициирует клиентский запрос, который может быть вызван нажатием кнопки в форме, да и вообще любым интерактивным действием, это может быть вызов web-сервиса или запуск платформы из bat-файла с автоматическим выполнением обработки, обращение через COM-соединение и так далее. Во всех этих случаях есть главная процедура, которая обрабатывает клиентский запрос. Именно она и должна начинать и фиксировать транзакцию. С точки зрения пользователя вложенных транзакций нет. Он либо получает атомарно изменения, которые инициировал, либо нет. В этом и заключается атомарность.
Сценарий транзакции должен начинать транзакцию и завершать ее, находясь в начале стека выполнения на сервере. Вызов извне будет только из клиентского события. Тогда не нужно оборачивать транзакцию в попытку, так как она откатится естественным образом. И никаких НачатьТранзакцию в глубине стека! Можно вызывать процедуры модификации данных, но они не должны начинать транзакции. Только код обработки клиентского запроса на верхнем уровне знает, когда начинается транзакция – собственно, когда обрабатывается клиентский запрос.
Не переписывать, а дополнять и немного изменять, если мы правильно спроектировали иерархию классов и предусмотрели возможность развития и быстрого внесения изменений. Все приложения сейчас обновляются, и это в порядке вещей. «Soft» в отличие от «Hard» мягкий, то есть изменчивый. Бухгалтерский софт обновляется с изменением законодательства, драйвера обновляются с выходом новых устройств, и т.д. Изменения в моделируемой предметной области влекут изменения в приложении, что в этом необычного? И если руки не кривые, можно будет использовать созданные классы в аналогичных проектах.
Давайте на примере. В классе «Транспортные средства» есть поля «Объем топливного бака, л» и «Расход топлива на 100 км». И мы реализовали функцию расчета, сколько можно проехать на полном баке без дозаправки «Максимальное расстояние» = Объем бака / Расход * 100. Отлично, но появляются летающие автомобили, которым требуется топливо на взлет и посадку. Мы добавляем класс «Летающий автомобиль» и поля «Расход топлива на взлет, л» и «Расход топлива на посадку, л». Если мы предусмотрительно объявили функцию «Максимальное расстояние» как виртуальную, то переопределяем ее: Расход на взлет + Объем бака / Расход * 100 + Расход на посадку. Как это сделать без ООП, если у нас один класс «Товары»?
Поэтому классификация в коде вводится не для того, чтобы разбить товары на группы или выделить какие-то опции. Классы различаются еще и поведением, то есть методами.
Зачем что-то выдумывать, чтобы назвать моделируемый объект? Если мы моделируем классы для хранения моделей плавательных средств и классы для хранения моделей автомобилей, то у них уже есть названия – это названия моделей. Например, для глиссирующего автомобиля-амфибии «Тритон» мы выберем имя класса Тритон.