Потому, что корабль это прежде всего сущность и кроме движения, он обладает другими признаками сущности, как-то параметры(скорость, колизии), ИИ и самое важное - способностью слать игрокам о себе информацию, используя сетевые пакеты.
Ну так всё это добро наследуется от L2Object - почему не реализовать все базовые для всех обьектов механики там? Это сразу разгрузит L2Character и позволит реализовать общий интерфейс IObject с общими для всех обьектов свойствами. А в L2Character оставить то, что характерно персонажам - скилы etc.
Отсылка пакетов вообще реализуется в потомках с третьего колена вроде - тех, которых нет на диаграмме как раз, и эти методы легко и непринуждённо становятся абстрактными, что превращает L2Object в AObject, что и верно, по сути.
Вам смущает количество строк? Почему? Вы можете попробовать сделать грамотную декомпозицию классов Character и Player, но для этого нужно понимать причины, вызвавшие такой размер и я не уверен, что среди этих 10000 строк вы найдете дубликаты кода для более чем 5%(Более того, когда к вам придет осознание того, что APlayble не должно существовать в принципе, эти классы прирастут еще 2-3к строк каждый) А также, в какие-то моменты опять же удобнее обратиться напрямую к родительскому типу сущности, чем делать очередной каст к нужному типу наследника, что в очередной раз снижает когнитивную нагрузку. Да и 10к строк там на самом деле не потому, что разработчики лыжи неквалифицированные идиоты, которые не понимают как писать код.
Разработчики не идиоты, но их много и коду дохерища лет - он прошел через кучу хроник. И постоянно там что-то пилили и пилят разные люди, что в принципе лишает возможности заняться рефакторингом. Там, например, хватает методов с пометкой Deprecated и TODO:delete this. Декомпозицию классов тоже начинаю делать. Например, кажется, в Character куча думми методов, что явно намекает на косяк в архитектуре в этой части кода - как минимум их можно безболезненно вынести в отдельный подкласс не нарушив структуры. Хотя правильнее будет вынести их в потомков, скорее всего.
Субъективщина. Мне например, более удобно когда основные проверки и часть логики предмета в одном классе, а не размазана на 20 слоев абстракций, т.к это снижает когнитивную нагрузку и прыгать в дебагере по десятку классов вместо одного метода - такое себе удовольствие. Кроме того, с постепенным узнаванием структуры лыжного ядра, вы поймете, что если в XML описано 2-3 поля итема, не означает, что у него 2-3 свойства, а означает, что остальные 50 полей имеют значение заданное по умолчанию.
В том то и дело, что имеют заданное по умолчанию. Но оно не используется, а тупо висит в памяти. А обьектов то много. Хотя я глянул, и наверно это был не Item, а что-то другое. Хотя его тоже можно разбить на отнаследованные подклассы, мне кажется.
Вот нафига, допустим, квест итему большая часть этих полей? Хз. Они просто есть.