Господа, у меня снова назрел вопрос. Есть такой код, вопрос в

строке 18. Как вызвать метод base_work()? В ООП это решилось бы наследованием и вызовом метода базового класса, но как идеоматично сделать в расте? Есть такие идеи, и обе не очень мне импонируют:
1. Сделать Base актором и отправлять сообщение из Derived
2. Сделать коллбек через CommonInteraction
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=56bcbd055c37f323738899ce887e1071

Перепроектировать без использования наследования. Убрать derived из Base и включить поле Base в Derived, например.

trait BaseInteraction { fn base_work(&self); } trait CommonInteraction: BaseInteraction { fn bar(&self); } это про наследование поведения а про наследование данных выше уже сказали

Либо fn bar(&self, base: Base) { // How to call Base::base_work? base.base_work(); }

если как тут, то <Self as BaseInteraction>::base_work(self) должно сработать

Я не очень понимаю позицию приходить и говорить "архитектура фигня, переделай вот так и будет норм". Это не помощь, это помеха: я не могу переделать, и боевой код выглядит именно так, как я скинул - сверху накручено ещё много другого кода и логика предметной области

Из 10 строчек кода всё это не вывести.

вообще как мне кажется идеалогия раста композиция вместо наследования - в идеале переходить на нее тогда проблем будет сильно меньше (иначе будет бой с технологией имхо)

Вы же понимаете, что с плохой архитектурой или дизайном дальше проблем и костылей будет становиться только больше? И лучше бы переделать ("отрефакторить") как можно раньше, пока не навернули ещё больше поверх?

Понимаю. Но там Derived в Base находится не просто так, того требует предметная область. Наоборот один в другое никак поместить нельзя

Ну... Я ведь там и пытаюсь перейти) Но чтоб обратиться к методу класса-агрегатора - нужен колбек

> того требует предметная область Не то, что бы у меня были основания Вам не верить, но утверждение сомнительное по своей форме — предметная область ничего от Вас не требует, Вы моделируете её как хотите/умеете/можете (в заданных условиях).

Ага, согласен. Но если в том коде выше что-то менять, то получится что-то вроде "а давайте сделаем не руку частью человека, а наоборот - человека частью руки"

в данном случае вижу 2 решения 1) имплементировать CommonInteraction для Base и сделать что нужно 2) делать колбек, но не понятно как будет вызываться base_work, ведь в Derived нет ни слова про Base

1) нельзя - опять же предметная область 2) нужно добавить Box<dyn FnMut()>, это да

А бывает и create table people(id, traits); create table body_parts(id, part_type, owner, stuff); Понимаете к чему я клоню?

Строить код на абстрактных представлениях о предметной области, а не на основе того, что нужно сделать - рискованная идея.

Только у вас скорее 'давайте отнаследуем человека от руки' :)

у вас наследование какое-то странное выходит, Base структурно больше чем Derived. С такой структурой base/derived - ну никак не сделать, нужно что-то менять