Архитектура MVC , ну и как это разрулить

Привет всем
Уже давно пишу 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();
        }
    }

Сообщение отредактировано: umf - 22.10.07, 23:01

umf, имхо, Вы весьма далеки от понимания MVC, по крайней мере расположение классов в пакетах не имеет никакого отношения к MVC и ещё, наследовать View от Model уж точно не нужно Я бы посоветовал ещё раз попытать разобраться в том, что такое MVC на примерах, например можно почитать эту статью:
http://lib.juga.ru/article/view/163/1/68/

Цитата umf @ 22.10.07, 23:01

Тоесть скажем так есть таблица с данными это класс T и ячейка в ней C
Теперь для отоброжения этой таблицы делаем класc TView который наследует T
И для ячейки CView наследующий C. И

Как уже сказали, это грубое нарушение MVC.

Тебе надо в сторону фабрики классов смотреть и интерфейсы использовать. Если я правильно понял что тебе надо.

2Felan: нашёт грубово нарушение MVC, структура MVC наследования не запрещает
кромето того это не MVC а просто немного на него похоже
и это тут к чему ?
"Тебе надо в сторону фабрики классов смотреть и интерфейсы использовать. Если я правильно понял что тебе надо."
фабрик хватает, интерфейсов тож

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

например

есть таблица с отображением это TView
теперь мы копируем в клипборд эту таблицу и в клибборде она представляется не как TView а как просто T
потом из клипборда копируем в приложение и из неё опять получается TView
при этом скажем метод установки значения ячейки setValue
в классе T будет только сохранять данные а в классе TView ещё и вызывать перересовку ячейки, есть ещё и представление TControl, и там кроме устаноки значения и перересовки дожны уведомлятся ещё и евент лисенеры о изменениях в ячейки

если всё это делать с агригацией то в дочерних классах придётся переписывать все методы базового класса

Сообщение отредактировано: umf - 23.10.07, 17:51

Цитата umf @ 23.10.07, 17:49

2Felan: нашёт грубово нарушение MVC, структура MVC наследования не запрещает

Наследование вьюхи от модели, можно сказать, запрещает.

Цитата umf @ 23.10.07, 17:49

2Felan: нашёт грубово нарушение MVC, структура MVC наследования не запрещает

и вообще изобретение новых антипаттернов только поощеряется

umf Еще раз свой топик прочитай, а потом еще раз прочитай вот эту свою фразу:

Цитата umf @ 23.10.07, 17:49

кромето того это не MVC а просто немного на него похоже

Цитата umf @ 23.10.07, 17:49

и это тут к чему ?
"Тебе надо в сторону фабрики классов смотреть и интерфейсы использовать. Если я правильно понял что тебе надо."
фабрик хватает, интерфейсов тож

Это к тому, что если у тебя действительно MVC то для создания модифицированных UI лучше всего использовать фабрику классов. А для этого надо хорошо продумать интерфейсы, т.к. в Java нет множественного наследования классов.

Цитата umf @ 23.10.07, 17:49

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

Я тебе еще раз говорю - так не делают! А если делают, то как раз имеют те проблемы про которые ты написал.
То, что ты пишешь во-первых, не имеет никакого отношения к делу. Т.к. люди полиморфизм придумали специально.
То, что ты пишешь во-вторых, решается продуманной архитектурой интерфейсов, которые должны реализовывать твои классы.

Цитата umf @ 23.10.07, 17:49

в классе T будет только сохранять данные а в классе TView ещё и вызывать перересовку ячейки, есть ещё и представление TControl, и там кроме устаноки значения и перересовки дожны уведомлятся ещё и евент лисенеры о изменениях в ячейки

У тебя класс таблицы должен сам уметь работать с клипбордом. И тогда не надо будте сохранять данные ни в каком классе Т. А классы TView и TControl должны работать с интерфейсом который предоставляет весь нужный функционал и реализуется классом таблицы.

Цитата umf @ 23.10.07, 17:49

если всё это делать с агригацией то в дочерних классах придётся переписывать все методы базового класса

Если все это сделать криво, то именно так и будет... А если правильно структуру классов сделать с использованием MVC и некоторых паттернов, то все будет просто замечательно.

ЗЫЖ Меня вообще удивляет факт: Ты просишь совета, тебе трое говорят, что так не делают, причем люди, как смотрю по форуму, знающие (Я себя не имею ввиду), а ты опять свое.

То, что ты сделал кривую архитектуру - бывает... Прими это как данность, пойми в чем проблема и в следующий раз так не делай. А если сам все знаешь - так зачем спрашивать???.

тихо да не наподайте вы так все
наверно обьяснил не совсем прально
попробую есчо раз
на примере

   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 архитектуры совсем не обязательно

Сообщение отредактировано: umf - 24.10.07, 08:35

Цитата umf @ 24.10.07, 08:32

вид ячейки содержит кеш для представления данных

Это в корне неправильно.
Переделай архитектуру. Потратишь некоторое время и будет тебе счастье.

В твоем примере должно быть примерно так:

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() );
        }
}

а где же кеш ?
у тя в paint напрямую вызывается cell.getRepresentationValue() и сответственно String.valueOf( value )
а я ведь написал допустим операция Integer.toString(data); занимает много времени, ну и String.valueOf( value ) тож, смысла то назваение функции не меняет

и ещё getRepresentationValue() этот метод относится к реализации просмотра ячейки а не к модели
тоесть должен находится в CellView, ведь модель мало интересует то как данные будут представленны пользователю
модель интересует только то как хранить данные чтобы к ним был быстрый и удобный доступ и по возможности чтобы они занимали немного места

Сообщение отредактировано: umf - 24.10.07, 14:00

Цитата umf @ 24.10.07, 13:58

а где же кеш ?

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

Цитата umf @ 24.10.07, 13:58

у тя в paint напрямую вызывается cell.getRepresentationValue() и сответственно String.valueOf( value )

У меня простой пример. Сделай этот метод как угодно. Хоть миллионом кэшей. Это МЕТОД и пишешь его как угодно тебе.

Цитата umf @ 24.10.07, 13:58

а я ведь написал допустим операция Integer.toString(data); занимает много времени, ну и String.valueOf( value ) тож, смысла то назваение функции не меняет

ДА это вообще к делу не относится. Это конкретная реализация, которую ты можешь писать как тебе вздумается.

Еще раз, это предельно просто пример АРХИТЕКТУРЫ а НЕ РЕАЛИЗАЦИИ. Реализацию я за тебя делать не буду. Мне есть чем заняться.

Цитата umf @ 24.10.07, 13:58

и ещё getRepresentationValue() этот метод относится к реализации просмотра ячейки а не к модели

Нет. Этот метод относится к классу Cell и возвращает значение в унифицированном формате (в данном случае String). Может быть я его немного неудачно назвал. Надо было getValueForRepresentation. А в просмотре ты берешь это значение через ICell из ЛЮБОГО класса реализующего этот ICell и отображаешь как тебе хочется.

Цитата umf @ 24.10.07, 13:58

тоесть должен находится в CellView, ведь модель мало интересует то как данные будут представлены пользователю

Все правильно. Модель и не знает как они будут представлены. Она просто предоставляет метод для получения этих данных в универсальном формате. Если у тебя есть Cell_Int и целым и Cell_Double, то что бы их использовать полиморфно и рисовать одним и тем же методом paint тебе надо унифицировать доступ.

Цитата umf @ 24.10.07, 13:58

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

Вот в моем случае как раз модель и хранит данные. В том числе и кэш. И работает с ним. А представление отображает. А у тебя каша какая-то

Сообщение отредактировано: Felan - 25.10.07, 04:38