Манипуляторы и манипулируемые + Основы ООП

[Izhic]

Я сегодня размышлял о манипуляции 3D объектами.
Вопрос заключался в том, кто должен быть главным,
манипулируемый объект(м2), или манипулятор(м1).
А точнее кто должен отлавливать сообщения о воздействии на объект.

Собственно давно этот вопрос волнует мой мозг.
На край подскажите, книгу по ООП(вероятно), где вопрос разобран доступно.
//Или Лучше статью.

Пример:
м1->м2
м1 = человек.
м2 = пульт.
Задача: Человек берёт пульт, или пульт берётся человеком?
1.Если пульт берётся человеком(м2<-м1), в этом случае, у пульта есть событие onAction. И она отлавливает воздействия на неё 3-их сил. В данном случае человека. - подумав, и размножив мысленно объекты, пришёл к выводу что будет колоссальная нагрузка на мир(процессор). Посмотрите вокруг, куча объектов, и все они проверяют не пытается ли кто-нибудь взаимодействовать с ними. + объект м2 управляет собой на своём уровне и сам изменяет свои свойства. м1 выполняет только свои роли, не вмешиваясь в жизнь м2.
2.Если человек берёт пульт(м1->м2), то в событии человека(м1), должно быть воздействие на методы и свойства пульта(м2).
Однако, получается что : м1 вмешивается в природу реакций м2.
К тому же, От этого, метод человека, по взаимодействию на предметы с разной природой будет сильно разбухать.
-> Внешнее воздействие.
-> Если использовать этот вариант, нужно сгруппировать методы и свойства м2, для уменьшения кода в м1.
3. Вариант, группируем 2 и 1 варианты.
Остаются только манипуляторы, как в 1 случае. Только они могут нести воздействие.
Силу для м2 даёт и воздействует м1. м2 создаёт собственное событие onAction, для воздействия на объекты, по траектории своего движения [м3-мx].
[м3-мx] при достаточности силы м2, так же станут манипуляторами.При отсутсвии силы, ловушка затухает(программно убиваем).

Подумав, я пришёл к выводу, что вариант 2, + ближе к 3-ему предпочтительнее.
Правильно ли моё предположение, и какие ещё варианты?

[SunKnight]

Мне кажется, что конечно манипулятор главенствующий. Причем один манипулятор может управлять множеством обьектов и не зависит от них. Конечно обьект сам может быть и манипулятором и объектом одновременно, т.е. иметь некий интерфейс приема сигналов с данными, а уже основываясь на этих входящих данных производить некоторые, допустим, расчеты и действия.

[Utkin]

Вариант 2 однозначно.

Однако, получается что : м1 вмешивается в природу реакций м2.

Почему однако? Если я положу пульт разве я не вмешиваюсь в природу его реакций? А если его брошу? Изменятся реакции? Конечно изменятся.

К тому же, От этого, метод человека, по взаимодействию на предметы с разной природой будет сильно разбухать.

Все зависит от Вашей модели. Нужно просто прописать конечный возможный набор воздействий. Допустим я не смогу умыться пультом, потому что такое действие в нашей Вселенной не определенно. Естественно скорость будет зависить от числа воздействий, но ведь можно и оптимизацию провести .

[Izhic]

SunKnight, понятно.
Utkin:

Если я положу пульт разве я не вмешиваюсь в природу его реакций?

Я в программном плане. Как бы желательно с точки зрения ООП, что бы объекты не зависели друг от друга.
//Для простого изменения Структуры.
Для этого имхо пусть каждый объект думает сам. Вот почему возник первый Вариант.

А если его брошу?

Сила воздействия + направление приложенной энергии. Обработка.
----------------------------------------
Вообще да в общем плане вероятно вариант 2(~3), но с методами максимально описанными в объекте м2.
Т.е. Простой Пример:

class TMovable
--------------.TryMove(xyz);

Пульт=new TMovable

Arm.OnAсtion={
if (Arm.Взаимодействует){
 Case(Arm.[КлассОбъектаВзаимодействия]){
TMovable:{
Arm.ВзаимодействуетObj.TryMove(Arm.xyz)
}}}}

[pu4koff]

Можно и третий класс ввести, чтобы человек с пультом общались через него.
человек -> некий контроллер <- пульт

можно будет добиться подобного:
человек.взять(пульт);
человек.взять(кирпич);

а контроллер уже будет решать как брать пульт, а как кирпич и что будет при этом происходить. Или же он будет вызывать соответствующие методы кирпича и пульта.
Чтобы снизить связность, можно выделить интерфейс для человека и для предмета, который можно брать. кирпич и пульт таким образом для контроллера будут "выглядеть" одинаково: как интерфейс "яХватаюсь"

[Utkin]

Сообщение от Izhic

SunKnight, понятно.
Utkin:
Я в программном плане. Как бы желательно с точки зрения ООП, что бы объекты не зависели друг от друга.
//Для простого изменения Структуры.
Для этого имхо пусть каждый объект думает сам. Вот почему возник первый Вариант.

Это уже давно придумано. В ОС есть система сообщений, можно использовать эту модель, когда объекты посылают друг другу некие сигналы и не вмешиваются во внутреннее состояние других.

И книга. Ну можно "ООП в действии" Тимати Бадд - там про ООП в частности и сравнение конкретных реализаций в различных языках (Делфи, Ява, С++ и пр.).

[Izhic]

topu4koff, мда понял, интерфейс, т.е. дополнительный прородительский класс. В своём примере постарался показать что-то подобное

toUtkin
Да, подходит, для АляБотов. Поэтому воздействие будет идти от разумных, или целенаправляющих(енных) объектов.
спасибо+. Книгу скачал.

Кстати обращение к .parent, это нормально или желательно, вероятно, строить систему, так что бы не обращаться к предкам? Т.е. вероятно всегда есть метод передать архитектуру так что бы обращение к предкам не происходило, но при том и не передавать каждый раз нужное свойство в методе...
ЗЫ://это к вопросу про связность и её уменьшение.

[mutabor]

Не нравятся предки? Используй утиную типизацию

[Utkin]

Можно подробней, что Вы хотите замутить? Полунамеками не совсем ясно решение какой задачи требуется.

[Izhic]

Аля шахматы/шашки... 2D->3d.
На общих где возможно классах.
------
В плане про parent, там допустим есть слой. Для каждого объекта уникальный. Поэтому нам нужен инкрементальный слой-глобальная переменная. Но ооп and [глобальные переменные ]==false

У меня(на бумаге в разработке) :

TValley={
Array of Polygone.Each.Create(layer)
}

TUnits={
Array of Unit.Each.Create(layer)
}

Game.layer=1;
Game.Valley=new TValley
Game.Units=new TUnits

Вероятно будут и другие постоянные как бы глобальные переменные.
Дак вот, в обоих Create, layer для каждого элемента массива будет увеличиваться.
И в Game так же.
Видимо в данном случае для Game , TValley, TUnits надо задать общий промежуточный класс(интерфейс?), с layer(в данном случае вроде вижу такой выход).
И потом обращаясь через prototype для абстрактного нашего класса, изменять сразу для всех значение layer

mutabor, прочёл я про утиную типизацию. Уж лучше предки

Пока займусь предложенной книгой.