Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.118.126.11] |
|
Сообщ.
#1
,
|
|
|
Привет всем
Уже давно пишу GUI приложение Весь проэкт разбил на основные пакеты как MVC Но пакетов немного больше, есть основной пакет данных, расширенный, пакет прорисивки и пакет управления, кроме того т.к. некоторые класы получаются слишком обёмными то элементы приходится разбивать на отдельные классы с наследованием. Например есть отдельно класс общего упровления, управления с клавиатуры и укравление мышью. Между пакетами классы наследуют друг друга, а внутри пакета связанны между собой ссылками. И вот получается что для досупа к нужному классу приходится либо делать привидение типов либо писать дополнительные методы, и в большом количестве. Тоесть скажем так есть таблица с данными это класс T и ячейка в ней C Теперь для отоброжения этой таблицы делаем класc TView который наследует T И для ячейки CView наследующий C. И вот если в ячейки есть ссылка на таблицу T а нам нужем метод из TView в коде CView то надо использовать приведение типов или писать дополнительный метод для получения ссылки на TView. Есть ли какойто вариант упростить доступ к TView? Вот пример кода public class T { } public class C { private T t; public C(T t) { this.t=t; } public T t() { return t; } } public class TView extends T { public void a() { } } public class CView extends C { public CView(TView t) { super(t); } public void callA() { ((TView) t()).a(); } } |
Сообщ.
#2
,
|
|
|
umf, имхо, Вы весьма далеки от понимания MVC, по крайней мере расположение классов в пакетах не имеет никакого отношения к MVC и ещё, наследовать View от Model уж точно не нужно Я бы посоветовал ещё раз попытать разобраться в том, что такое MVC на примерах, например можно почитать эту статью:
http://lib.juga.ru/article/view/163/1/68/ |
Сообщ.
#3
,
|
|
|
Цитата umf @ Тоесть скажем так есть таблица с данными это класс T и ячейка в ней C Теперь для отоброжения этой таблицы делаем класc TView который наследует T И для ячейки CView наследующий C. И Как уже сказали, это грубое нарушение MVC. Тебе надо в сторону фабрики классов смотреть и интерфейсы использовать. Если я правильно понял что тебе надо. |
Сообщ.
#4
,
|
|
|
2Felan: нашёт грубово нарушение MVC, структура MVC наследования не запрещает
кромето того это не MVC а просто немного на него похоже и это тут к чему ? "Тебе надо в сторону фабрики классов смотреть и интерфейсы использовать. Если я правильно понял что тебе надо." фабрик хватает, интерфейсов тож теперь почему классы наследуют друг-друга вопервых многие методу переопределлены в дочерних классах вовторых досуп к методам базового класса должен быть такойже как и к методам дочернего например есть таблица с отображением это TView теперь мы копируем в клипборд эту таблицу и в клибборде она представляется не как TView а как просто T потом из клипборда копируем в приложение и из неё опять получается TView при этом скажем метод установки значения ячейки setValue в классе T будет только сохранять данные а в классе TView ещё и вызывать перересовку ячейки, есть ещё и представление TControl, и там кроме устаноки значения и перересовки дожны уведомлятся ещё и евент лисенеры о изменениях в ячейки если всё это делать с агригацией то в дочерних классах придётся переписывать все методы базового класса |
Сообщ.
#5
,
|
|
|
Цитата umf @ 2Felan: нашёт грубово нарушение MVC, структура MVC наследования не запрещает Наследование вьюхи от модели, можно сказать, запрещает. |
Сообщ.
#6
,
|
|
|
Цитата umf @ 2Felan: нашёт грубово нарушение MVC, структура MVC наследования не запрещает и вообще изобретение новых антипаттернов только поощеряется |
Сообщ.
#7
,
|
|
|
umf Еще раз свой топик прочитай, а потом еще раз прочитай вот эту свою фразу:
Цитата umf @ кромето того это не MVC а просто немного на него похоже Цитата umf @ и это тут к чему ? "Тебе надо в сторону фабрики классов смотреть и интерфейсы использовать. Если я правильно понял что тебе надо." фабрик хватает, интерфейсов тож Это к тому, что если у тебя действительно MVC то для создания модифицированных UI лучше всего использовать фабрику классов. А для этого надо хорошо продумать интерфейсы, т.к. в Java нет множественного наследования классов. Цитата umf @ теперь почему классы наследуют друг-друга вопервых многие методу переопределлены в дочерних классах вовторых досуп к методам базового класса должен быть такойже как и к методам дочернего Я тебе еще раз говорю - так не делают! А если делают, то как раз имеют те проблемы про которые ты написал. То, что ты пишешь во-первых, не имеет никакого отношения к делу. Т.к. люди полиморфизм придумали специально. То, что ты пишешь во-вторых, решается продуманной архитектурой интерфейсов, которые должны реализовывать твои классы. Цитата umf @ в классе T будет только сохранять данные а в классе TView ещё и вызывать перересовку ячейки, есть ещё и представление TControl, и там кроме устаноки значения и перересовки дожны уведомлятся ещё и евент лисенеры о изменениях в ячейки У тебя класс таблицы должен сам уметь работать с клипбордом. И тогда не надо будте сохранять данные ни в каком классе Т. А классы TView и TControl должны работать с интерфейсом который предоставляет весь нужный функционал и реализуется классом таблицы. Цитата umf @ если всё это делать с агригацией то в дочерних классах придётся переписывать все методы базового класса Если все это сделать криво, то именно так и будет... А если правильно структуру классов сделать с использованием MVC и некоторых паттернов, то все будет просто замечательно. ЗЫЖ Меня вообще удивляет факт: Ты просишь совета, тебе трое говорят, что так не делают, причем люди, как смотрю по форуму, знающие (Я себя не имею ввиду), а ты опять свое. То, что ты сделал кривую архитектуру - бывает... Прими это как данность, пойми в чем проблема и в следующий раз так не делай. А если сам все знаешь - так зачем спрашивать???. |
Сообщ.
#8
,
|
|
|
тихо да не наподайте вы так все
наверно обьяснил не совсем прально попробую есчо раз на примере class Cell { int data; } class Table { Cell[] cells; } class TableView extends Table { int currentPosition; } class CellView extends Cell { String cacheOfTextRepresentationOfData; void paint() { if(cacheOfTextRepresentationOfData==null) cacheOfTextRepresentationOfData=Integer.toString(data); drawString(cacheOfTextRepresentationOfData); } } таблица содержит ячейки, ячейки содержат данные вид ячеки содержит кеш для представления данных( допустим операция Integer.toString(data); занимает много времени) итак куда теперь предложите этот кеш поставить да и совсем забыл, прошу не придератся к названию темы MVC, применение MVC архитектуры совсем не обязательно |
Сообщ.
#9
,
|
|
|
Цитата umf @ вид ячейки содержит кеш для представления данных Это в корне неправильно. Переделай архитектуру. Потратишь некоторое время и будет тебе счастье. В твоем примере должно быть примерно так: public interface ICell{ public String getRepresentationValue(); } class Cell_int implements ICell{ int value; public String getRepresentationValue() { return String.valueOf( value ); } } class Cell_String implements ICell{ String value; public String getRepresentationValue(){ return value; } } class Table{ ICell[] cells; } class CellView{ void paint(ICell cell){ if(cell == null) drawString( cell.getRepresentationValue() ); } } |
Сообщ.
#10
,
|
|
|
а где же кеш ?
у тя в paint напрямую вызывается cell.getRepresentationValue() и сответственно String.valueOf( value ) а я ведь написал допустим операция Integer.toString(data); занимает много времени, ну и String.valueOf( value ) тож, смысла то назваение функции не меняет и ещё getRepresentationValue() этот метод относится к реализации просмотра ячейки а не к модели тоесть должен находится в CellView, ведь модель мало интересует то как данные будут представленны пользователю модель интересует только то как хранить данные чтобы к ним был быстрый и удобный доступ и по возможности чтобы они занимали немного места |
Сообщ.
#11
,
|
|
|
Цитата umf @ а где же кеш ? Кэш должен быть в классе Cell. Или вообще отдельно, и должен быть просто связана с объектами ячеек, если уж тебе так принципиально он нужен и ты действительно хочешь от него мега оптимизацию и быстроту. Цитата umf @ у тя в paint напрямую вызывается cell.getRepresentationValue() и сответственно String.valueOf( value ) У меня простой пример. Сделай этот метод как угодно. Хоть миллионом кэшей. Это МЕТОД и пишешь его как угодно тебе. Цитата umf @ а я ведь написал допустим операция Integer.toString(data); занимает много времени, ну и String.valueOf( value ) тож, смысла то назваение функции не меняет ДА это вообще к делу не относится. Это конкретная реализация, которую ты можешь писать как тебе вздумается. Еще раз, это предельно просто пример АРХИТЕКТУРЫ а НЕ РЕАЛИЗАЦИИ. Реализацию я за тебя делать не буду. Мне есть чем заняться. Цитата umf @ и ещё getRepresentationValue() этот метод относится к реализации просмотра ячейки а не к модели Нет. Этот метод относится к классу Cell и возвращает значение в унифицированном формате (в данном случае String). Может быть я его немного неудачно назвал. Надо было getValueForRepresentation. А в просмотре ты берешь это значение через ICell из ЛЮБОГО класса реализующего этот ICell и отображаешь как тебе хочется. Цитата umf @ тоесть должен находится в CellView, ведь модель мало интересует то как данные будут представлены пользователю Все правильно. Модель и не знает как они будут представлены. Она просто предоставляет метод для получения этих данных в универсальном формате. Если у тебя есть Cell_Int и целым и Cell_Double, то что бы их использовать полиморфно и рисовать одним и тем же методом paint тебе надо унифицировать доступ. Цитата umf @ модель интересует только то как хранить данные чтобы к ним был быстрый и удобный доступ и по возможности чтобы они занимали немного мест Вот в моем случае как раз модель и хранит данные. В том числе и кэш. И работает с ним. А представление отображает. А у тебя каша какая-то |