ЛагманУ вас проблемы с восприятием примеров, и с ООП.

У вас проблемы с кодированим и культурой общения. Меня каждый раз умиляет как джуниоры из года в год ваяют подобные страницы кода, которые не делают ничего полезного и заменяются парой методов и классом.

ЛагманmaytonЛагман, y нас есть необходимость сортировать также null значения.
У вас проблемы с восприятием примеров.
Алсо своим воторым вопросом вы отвечаете на свой первый.
Мой рефакторинг первоначального кода точно так же справляется с null значениями, как и оригинальный код. Без копараторов.

А вот подобный код в проекте


это бесполезный шум. Не нужен компаратор, так где есть Comparable. Не нужно два разных компаратора для двух Comparable типов. Такой код не несет никакой пользы. Просто усложяет код, не более.

HoBTIDМой вопрос слишком сложен для местной массы?

Конечно. Мы тут тупая масса идиотов. Куда нам до Вас.

HoBTIDНастолько сложен, что даже непонятно о чем это?
Тихо сам с собою я ведь беседу.

HoBTIDЕсли же вам потом понадобится нечто "очень бизнесовое", добавьте в эту табличку колонку с id,
по которому потом можно создать сущность.
В чем преимущества? Вы предлагаете решение без очевидных достоинств и требуете доказательств что оно не самое оптимальное?

HoBTIDПреимущества в простой сортировке и фильтрации такой таблицы, без рефлексии.

Моя версия решения проблемы не использует рефлексию.
Задача сортировка списка списков по элементу внутреннего списка слабо отличается от задачи сортировки списка бинов по свойству.

HoBTIDФункции работы с ней универсальны, все что им нужно, это чтобы значения в одной колонке были сравнимы между собой.
Забудьте слово "универсальный".

HoBTIDОсознаете ли Вы значение слова "говнокод"???

Многоуважаемое хамло. На данный момент это наиболее простой и компактный код приведенный в этой теме и соответствующий семантике оригинального метода. Вашего кода мы пока в теме не увидели.

HoBTIDДаже если предположить, что слабо отличается
(не хочу сейчас углубляться в случаи, когда она отличается очень сильно), как ее реализовать?
Правильно, углублятся не нужно. Пукнул в лужу и пошел. Код привести не можем. Обосновать его преимущество не можем. Хамить - всегда пожалуйста.

HoBTIDВ случае бинов - только рефлексией или же забитыми гвоздями switch или if.
Ну, у вас, вероятно, если более разумные и "универсальные" идеи как привязать свойства к индексам полей. Только вы нам их не расскажите, как я понял.

HoBTIDМне жаль, что вы его забыли, уж я-то не забуду никогда.
Слово "универсальный" это то как джуниоры описывают свой код. Они понятия не имееют о таких критериях, как связанность, сцепление, читаемость, ошибкоустойчивость к будущим изменениям и т.п. У них на всё один критерей "универсальный". Я из этого возраста давно вышел, поэтому данным словом код никогда не измеряю.

HoBTIDКода будет довольно много, я его писал в одном из проектов.

Ну, вот и я о том же.

HoBTIDЗато он не зависит от сущности, это я называю словом "универсальный".

Ну, так бины тогда можно вообще выкинуть и писать всё на массивах и хэшмапах. На форумах каждые два года появляется нуб с такой "оригинальной" и "универсальной" идеей.

HoBTIDЕсли у вас недопонимание этого слова в связи с психическими травмами получеными в джуниорском периоде,
это не значит, что и у других похожие травмы.

Да, всё понятно уже. Можешь дальше не закатывать истерику.

HoBTIDНу что ж, пожалуй напишу азы, вдруг кто-нибудь поймет?



Круто ваще. Как я сразу об этом не подумал. Спасибо, сансэй.

HoBTIDОсталось написать класс ColumnDef - описание колонки, и различные методы класса VisualTableModel,
вот тут кода будет много,

Какая мелочь.

HoBTIDно за соответствующее вознаграждение, я готов его предоставить.
Куда переводить?

HoBTIDИ Ваш код удовлетворяет критерию слабой связности, например?
Или, может быть, он ошибкоустойчивый к будущим изменениям?
Это здесь при чем? Это же не я заявляю об "универсальности".
Мой код лаконичный - пока что не вижу чтобы кто-то более простое решение предложил. Полностью сохраняет семантику оригинального метода. Полностью сохраняет изначальный дизайн, класс, который отвечал за маппинг индекса на свойства, всё так же за это и отвечает. Это не значит что я с первоначальным дизайном согласен. Поэтому и порекомендовал унести маппинг индекса на свойства в саму сущность.

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

У меня на проекте имеется ArrayBeanTableModel, универсальный для всех сущностей. Без всяких матриц. Никак от детипизации я не страдаю. Ваше же решение сродни динамической типизации. Никакой возможности контролировать что там в матрице и как-то этим пользоваться. Единственное что можно делать, это выводить на View. Какая-от сомнительная универсальность выходит.

HoBTIDТ.е. у себя вы используете решение, не зависящее от типа сущности, а автору темы предлагаете зависящее. Оригинально.

Автору я предлагаю решение проблемы о которой он спросил. А не переписать половину проекта под "универсальное" решение.

HoBTIDИ на каком же принципе оно основано? Дайте угадаю, рефлексия?

С фига ли? Мапятся колонки на свойства схожим образом через switch case. У меня гриды на View слишком динамично меняются и довольно сильно отличаются от модели. Поэтому существует отдельный слой маппинга модели на гриды.
Зато через него всегда доступна строго типизированя модель, через которую я всегда могу запускать бизнес-логику, конкретного типа. В вашем же решении, отдельно матрица только для просмотра, отдельно список сущностей где-то ещё, либо списка вообще нет, и сущности каждый раз пересобираеются из матрицы без какого либо контроля типов. Действительно что может быть проще и универсальнее массива массивов.

HoBTIDДействительно, контролировать ничего не нужно, т.к. данные через эту матрицу не редактируются, только выводятся для просмотра.
Редактирование строчки нужно делать уже через сущность в отдельной форме.

Оу, но теперь понятно всё. Т.е. данные можно только редактировать и показывать. Теперь мы пришли к тому что матрица сразу делает грид не доступным для радактирования, а лишь только через отдельную форму. Очень "универсально".


HoBTIDПреимущество в том, что матрица реализует все требования к списку для просмотра
(сортировка, фильтрация, может быть реализовано постраничная загрузка) и этим не нужно заморачиваться в сущностях.
У меня есть сортировка, и постраничная загрузка. Фильтрация унесена на уровнеь работы с базой. Локально фильтровать сущности, как-то странно и не эффективно. И всё это на типизировном списке сущностей, без матрицы.

HoBTIDswitch case независимо от типа сущности? Я поражен.
Или же для каждой сущности есть отдельный объект маппинга, куда спрятан этот switch, и это Вы называете "независимо"?

Прикинь, да. Модель на View надо как-то маппить. Эка неожиданность для гуру дизайна. Правда?
В вашем решении возможны два варианта. Либо вы в матрицу вываливаете всё что только можно. Каким образом, например, гарантировать порядок колонок?
Либо у вас присутствует точно такой же маппинг, но в неявном виде. Что затрудняет его поддержку.

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

Добро пожалуйвать в чудесный мир Anemic Domain Model.

HoBTIDОтдельного списка сущностей нет, сущность загружается из БД или берется из кэша, при начале редактирования.

Мы уже поняли, что у вас кроме просмотра редактирования, другой логики быть не может. Можно не продолжать.

HoBTIDИз матрицы пересобирать не совсем корректно, т.к. она может не содержать всех колонок, и уж точно не содержит табличных частей.
Ну, понятно. Все прелести Anemic Domain Model. Если нужна логика для конктретного типа, она будет реализована прям там в таблице с матрицей этого типа. Это очень удобно, не нужно вообще париться о разделении модели и представлении.
До тех пор пока одна и та же логика вдруг не потребуется на нескольких разных слоях.

maytonТут цена вопроса - "сферический проект в вакууме" или уже имеющийся проект
который писали в определённом ключе.
Как можно?! Саппорт это для джуниоров. Гуру дизайна всё пишет с нуля!