Портянки:
Заменить на тернарный оператор:
И

Ginosaji, Тернарники в общем случае только ухудшают читабельность и не расширяемы емли нужно дописать парочку else if

Naik, кстати, согласен насчёт тернарников. С ними код растёт в ширину, а это куда хуже для чтения. Для коротких выражений ещё можно, но последнее составное условие для тернарника явно перебор.

Можно, конечно, форматировать.

aNNiMON,
строчки с 22 по 57 превратятся в date = getDate(context, i, model);А как же то, что там используются переменные labelFormatter, todayLocalDate, oldLocalDate, oldDateString?

Сейчас даты создаются один раз, а будут каждую итерацию, а обьект oldDateString и подобные обьекты которые зависят от других элементов списка и динамически меняются придется передавать тоже в getDate(...)

Naik, тогда вместо передачи i, oldDateString и oldLocalDate, можно передать результат вычисления выражения (i == 0 || (!todayLocalDate.equals(oldLocalDate) && !dateString.equals(oldDateString))), завёрнутый в Predicate

Без InsertSectionType все получается намного проще, вот вставка дат в обьекты где просто нужно ориентироваться на какую-то дату

Открыть спойлер

Закрыть спойлер

[копировать] [скачать]

1. public static List<BaseModel> insertSectors(Context context, List<? extends ISectioned> src,
2.                                                 boolean insertMonthSectors,
3.                                                 LabelFormatter labelFormatter) {
4.         if (src == null || src.size() == 0) return Collections.emptyList();
5.  
6. [code]    List<BaseModel> models = new ArrayList<>((int) (src.size()));
7.     String oldDateString = null;
8.     LocalDate oldLocalDate = null;
9.     ISectioned model;
10.     int oldMonthOfYear = -1;
11.     int oldYear = -1;
12.     final int currentYear = new LocalDate().getYear();
13.     for (int i = 0; i < src.size(); i++) {
14.         model = src.get(i);
15.         Date date = model.getSectionDate();
16.         if (date != null) {
17.             date = DateTimeUtils.fromUTC(date);
18.             LocalDate localDate = new LocalDate(date);
19.             String dateString = labelFormatter.format(context, model, date);
20.             if (insertMonthSectors) {
21.                 final int monthOfYear = localDate.getMonthOfYear();
22.                 final int year = localDate.getYear();
23.                 if (i != 0 && (monthOfYear != oldMonthOfYear || year != oldYear)) {
24.                     models.add(new EventListMonthSectorHeader(-(year + 13 + monthOfYear), localDate, year != currentYear));
25.                 }
26.                 oldMonthOfYear = monthOfYear;
27.                 oldYear = year;
28.             }
29.             if (i == 0 || (!localDate.equals(oldLocalDate) && !dateString.equals(oldDateString))) {
30.                 models.add(new SimpleItem<>(dateString, -date.getTime()));
31.             }
32.             oldLocalDate = localDate;
33.             oldDateString = dateString;
34.         }
35.         models.add(model);
36.     }
37.     return models;
38. }

[/code]

Naik, дело вкуса. Я пишу if else цепочки, только при сравнении разнородных вещей, а если можно, то либо тернарник форматированный, либо switch для однородных.

Ну и ещё на мой вкус, я не люблю слишком длинные if блоки, да ещё и с большой вложенностью, потому что прокрутив вниз, можно и забыть, что там вверху условия какие-то.

Я бы сделал:

Скажите что не так в коде написано. ООП, или вообще логика. Что лишние, а что стоило бы добавить?

Пост #490975

2.

Лихой синглтон

Лихой синглтон

[копировать] [скачать]

1. public class MyGame extends Game {
2.     public static MyGame game;
3. ...
4.  
5. class ApplicationLauncher {
6. ...
7.     MyGame.game = new MyGame();

Лихо ты сделал синглтон. Коль так, мог бы хоть не разбрасывать его по куче классов, а инициализировать в одном месте, как в нормальном синглтоне:

[копировать] [скачать]

1. public class MyGame extends Game{
2.  
3.     public static MyGame game;
4.  
5.     public static MyGame getInstance() {
6.         if (game == null) {
7.             game = new MyGame();
8.         }
9.         return game;
10.     }
11. ...
12. new LwjglApplication(MyGame.getInstance(), cnf);

Ну, ООП ж знаешь, должен же понимать, как синглтон делать и почему он -- антипаттерн.

И, я гляжу, ты любишь такое использовать. В ApplicationLauncher, Asset тоже статическая ссылка на объект.

load()

load()

Во многих классах есть метод load(), можно было это в интерфейс какой-нибудь закинуть. Как минимум для улучшения читабельности, чтоб сразу понять, что этот класс представляет объект, который может загружаться, то есть ресурс какой-то, текстура, карта и т.д.

Инициализаторы вне конструкторов

Инициализаторы вне конструкторов

1. class World {
2. public ArrayList<WorldObject> objectes = new ArrayList<>();

Всегда против такого. Заполнение полей должно происходить в конструкторе, а не при объявлении. Вот этот код автоматически влепит objectes = new ArrayList<>(); в каждый конструктор.

addStatic/addDynamic

addStatic/addDynamic

[копировать] [скачать]

1. public void add(WorldObject ob, boolean stat){
2.     this.objectes.add(ob);
3.     if(stat){
4.         gridObject.addStatic(ob);
5.     }else{
6.         gridObject.addDynamic(ob);
7.     }
8. }

А не лень каждый раз вспоминать, какой объект статичный, а какой динамичный? Пометил бы классы объектов соответствующими интерфейсами или отнаследовал от классов (например, StaticGridObject/DynamicGridObject), а в WorldGridObject сделал бы два перегруженных метода:

1. public void add(StaticGridObject ob) { .. }
2. public void add(DynamicGridObject ob) { .. }

и тогда не нужно было делать такие проверки и передавать флажки.

Повторяющийся код - зло. Повторяющийся код - зло.

Повторяющийся код - зло. Повторяющийся код - зло.

Повторяющийся код - зло. Повторяющийся код - зло. Повторяющийся код - зло. Взгляни на методы addStatic и addDynamic класса WorldGridObject и найди десять отличий. Отличие лишь в результирующем массиве, куда будут положены объекты.
Взгляни на остальные методы этого класса и ты увидишь 8 одинаковых строк в каждом из них? Тебе не лень было их писать? Уже на третьем методе можно было бы задуматься об этом и вынести, наконец, в новый метод.

fin

fin

В остальном вроде всё нормально. Одиночные классы из пакетов можно было бы выделить в какой-нибудь пакет screens.

aNNiMON, Спасибо. Я вот эту сетку объектов из книги взял. Книга по gamedev для андроид.
Прям с самого начала хотел сделать, что бы просто объект добовлять, а там внутри уже будет typeObject unum-перечесление, ну или хотя бы inte typeObject и статичные финальные DynamicObject и StaticObject.
Сама сетка - вот проблема.
А так из моего это только статичные переменные прямым доступом, как я понял.