|
|
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Blazkowicz6) Подумать почему Код: plaintext лучше чем Код: plaintext 1. 2. 3. 4. Хотя нет. Это ещё спорный вопрос. Можно ещё фабрику прикрутить и флейм по этому поводу развести. Так что в контексте этого примера может быть и нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2006, 19:36 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
JozicНу и наследование шарика от таймерТаск из ноу гуд (вери мач). Сейчас у меня получается такая ситуация. Шар имеет возможность двигаться. Его дети, эту возможность приобретают от него и добавляют некую функциональность при движении (преопределение метода и вызов super.run()). Как тогда, лучше это реализуется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 11:32 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Blazkowicz4) Изучить проблемы наследования. Научится применять делегирование. Понять что из них и когда нужно использовать. Где можно почитать про делегирование? Правильно ли я понимаю, что interface и implemets - это оно и есть? TimerTask не является интрефейсом. Как, тогда, правельно его приминить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 12:06 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Что такое делегирование разобрался. Как решить следующую задачу: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Необходимо уйти от наследования TimerTask и иметь возможность расширить метод run(); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 13:58 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
AkhЧто такое делегирование разобрался. Как решить следующую задачу: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Необходимо уйти от наследования TimerTask и иметь возможность расширить метод run(); Что-то типа такого. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Можно попробовать и BallsCollision extends TimerTask, по-моему нормально будет. Для начала было бы не плохо задуматся какой класс какие цели преследует. И строго ограничить назначение классов. Это и называется инкапсуляция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 14:30 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
BlazkowiczЧто-то типа такого. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Можно попробовать и BallsCollision extends TimerTask, по-моему нормально будет. Для начала было бы не плохо задуматся какой класс какие цели преследует. И строго ограничить назначение классов. Это и называется инкапсуляция. Это не то, что я хочу. Я хочу инкапсулировать в один класс, направление движеня и само движение. Сейчас это класс Ball. Его дети должны уметь добавлять логику в движение в соответствии с их особенностями. Мне кажется, что такой подход более удобен и корректен. Т.о. получается, что класс Ball должен иметь таймер, а наследники его должны уметь его дополнять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 15:14 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Инкапсулировать в один класс сам шар и движение - я имею ввиду, что он должен этому соответствовать, что не означает, что хочу, чтобы это решалось одним классом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 15:18 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Akh Я хочу инкапсулировать в один класс, направление движеня и само движение. 8) "Инкапсулировать" не есть "запихнуть всё". А запихнуть что-то конкретное. Тут надо вернутся к MVC. Направление это Model, а логика движения это Controller. Конечно никто не запрещает это все в одном классе хранить. Но есть практика и убедительные доводы в пользу этого подхода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 15:21 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Blazkowicz8) "Инкапсулировать" не есть "запихнуть всё". А запихнуть что-то конкретное. Тут надо вернутся к MVC. Направление это Model, а логика движения это Controller. Конечно никто не запрещает это все в одном классе хранить. Но есть практика и убедительные доводы в пользу этого подхода. Как тогда это представлять? Есть набор классов шаров и класс контроллер, который умеет их двигать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 15:28 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Что-то типа такого? Надеюсь смысл понятен. Такие структуры не писал, поэтому, где-то может быть ошибка. Если смысл правельный, прошу поправить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 15:34 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Получается надо создавать шар: Код: plaintext 1. 2. 3. 4. 5. 6. Это хорошее решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 15:43 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
Не знаю насколько это правильно. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 15:45 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
wolf_romaНе знаю насколько это правильно. Как начинающему жаба-программисту, кажится странным с точки зрения ООП, что, внутренний класс имеет непосредственный доступ к методам внешнего класса. Но так работает, и программа выглядит проще, т.к. в данном случае нет повода строить по MVC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2006, 17:18 |
|
||
|
Структура классов и их взаимосвязь
|
|||
|---|---|---|---|
|
#18+
AkhНо так работает, и программа выглядит проще, т.к. в данном случае нет повода строить по MVC Конечно, чем ближе к MVC , тем проще выглядит. А если ты про то что исходная модель хорошо работает.... Думаю ты переутомился, ИМХО всё должно быть гораздо проще. По делу: Слишком уж много логики в бедном шарике (даже моторчик встроен) И вообще надо сокращать. Простота кода залог его расширяемости. Я бы убрал область движений(странно каждый шар в своей области, по 4 координаты), зачем какие-то movingX да ещё интовые?? Вполне достаточно скорости по проекциям, а я бы вообще сделал 1скорость и угол(направление). Думаю другие классы тоже можно упростить. Ну конечно правильно было бы оставить в шаре только сеттергеттеры. Мне нравится такая модель: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Интересно, а что в TimerTask, помоему он и есть контроллер,нужно ли его расширять. А в каких направлениях планируются расширения?? если будет много шариков, надо бы наладить делегирование ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2006, 04:51 |
|
||
|
|

start [/forum/topic.php?fid=59&gotonew=1&tid=2148413]: |
0ms |
get settings: |
11ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
72ms |
get topic data: |
13ms |
get first new msg: |
8ms |
get forum data: |
4ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 448ms |

| 0 / 0 |
