|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
13.06.2009, 09:42 | #1 | |
Форумчанин
Регистрация: 08.10.2008
Сообщений: 668
|
Манипуляторы и манипулируемые + Основы ООП
Я сегодня размышлял о манипуляции 3D объектами.
Вопрос заключался в том, кто должен быть главным, манипулируемый объект(м2), или манипулятор(м1). А точнее кто должен отлавливать сообщения о воздействии на объект. Собственно давно этот вопрос волнует мой мозг. На край подскажите, книгу по ООП(вероятно), где вопрос разобран доступно. //Или Лучше статью. Цитата:
Правильно ли моё предположение, и какие ещё варианты?
Don't worry be happy
Последний раз редактировалось Izhic; 13.06.2009 в 10:25. |
|
13.06.2009, 10:20 | #2 |
Участник клуба Подтвердите свой е-майл
Регистрация: 14.12.2007
Сообщений: 1,434
|
Мне кажется, что конечно манипулятор главенствующий. Причем один манипулятор может управлять множеством обьектов и не зависит от них. Конечно обьект сам может быть и манипулятором и объектом одновременно, т.е. иметь некий интерфейс приема сигналов с данными, а уже основываясь на этих входящих данных производить некоторые, допустим, расчеты и действия.
Проповедую design patterns, верую в MVC, доверяю eXtrime programming.
|
13.06.2009, 10:50 | #3 | ||
Старожил
Регистрация: 04.02.2009
Сообщений: 17,351
|
Вариант 2 однозначно.
Цитата:
Цитата:
Маньяк-самоучка
Utkin появился в результате деления на нуль. Осторожно! Альтернативная логика |
||
13.06.2009, 11:15 | #4 | ||
Форумчанин
Регистрация: 08.10.2008
Сообщений: 668
|
SunKnight, понятно.
Utkin: Цитата:
//Для простого изменения Структуры. Для этого имхо пусть каждый объект думает сам. Вот почему возник первый Вариант. Цитата:
---------------------------------------- Вообще да в общем плане вероятно вариант 2(~3), но с методами максимально описанными в объекте м2. Т.е. Простой Пример: Код:
Don't worry be happy
Последний раз редактировалось Izhic; 13.06.2009 в 11:25. |
||
13.06.2009, 11:28 | #5 |
Старожил
Регистрация: 22.05.2007
Сообщений: 9,085
|
Можно и третий класс ввести, чтобы человек с пультом общались через него.
человек -> некий контроллер <- пульт можно будет добиться подобного: человек.взять(пульт); человек.взять(кирпич); а контроллер уже будет решать как брать пульт, а как кирпич и что будет при этом происходить. Или же он будет вызывать соответствующие методы кирпича и пульта. Чтобы снизить связность, можно выделить интерфейс для человека и для предмета, который можно брать. кирпич и пульт таким образом для контроллера будут "выглядеть" одинаково: как интерфейс "яХватаюсь" |
13.06.2009, 11:33 | #6 | |
Старожил
Регистрация: 04.02.2009
Сообщений: 17,351
|
Цитата:
И книга. Ну можно "ООП в действии" Тимати Бадд - там про ООП в частности и сравнение конкретных реализаций в различных языках (Делфи, Ява, С++ и пр.).
Маньяк-самоучка
Utkin появился в результате деления на нуль. Осторожно! Альтернативная логика |
|
13.06.2009, 11:59 | #7 |
Форумчанин
Регистрация: 08.10.2008
Сообщений: 668
|
topu4koff, мда понял, интерфейс, т.е. дополнительный прородительский класс. В своём примере постарался показать что-то подобное
toUtkin Да, подходит, для АляБотов. Поэтому воздействие будет идти от разумных, или целенаправляющих(енных) объектов. спасибо+. Книгу скачал. Кстати обращение к .parent, это нормально или желательно, вероятно, строить систему, так что бы не обращаться к предкам? Т.е. вероятно всегда есть метод передать архитектуру так что бы обращение к предкам не происходило, но при том и не передавать каждый раз нужное свойство в методе... ЗЫ://это к вопросу про связность и её уменьшение.
Don't worry be happy
Последний раз редактировалось Izhic; 13.06.2009 в 12:08. |
13.06.2009, 12:02 | #8 |
Телепат с дипломом
Старожил
Регистрация: 10.06.2007
Сообщений: 4,929
|
Не нравятся предки? Используй утиную типизацию
The future is not a tablet with a 9" screen no more than the future was a 9" black & white screen in a box. It’s the paradigm that survives. (Kroc Camen)
Проверь себя! Онлайн тестирование | Мой блог |
13.06.2009, 12:04 | #9 |
Старожил
Регистрация: 04.02.2009
Сообщений: 17,351
|
Можно подробней, что Вы хотите замутить? Полунамеками не совсем ясно решение какой задачи требуется.
Маньяк-самоучка
Utkin появился в результате деления на нуль. Осторожно! Альтернативная логика |
13.06.2009, 12:24 | #10 |
Форумчанин
Регистрация: 08.10.2008
Сообщений: 668
|
Аля шахматы/шашки... 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, прочёл я про утиную типизацию. Уж лучше предки Пока займусь предложенной книгой.
Don't worry be happy
Последний раз редактировалось Izhic; 13.06.2009 в 14:23. |
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Основы FastReport | Dima_mazhor | БД в Delphi | 31 | 13.12.2009 15:34 |
Паскаль ООП. Примеры программ с использованием ООП | SeЯgey | Помощь студентам | 5 | 13.05.2009 21:55 |
ADO основы... | Roof | БД в Delphi | 14 | 10.12.2007 21:28 |