запуск ядра java не через bat а через c#

[krisadr]

Вот вот, а то, что логика всего раза хана по всему ядру... Это пи зд ц полный. Приду домой скину набросок схемы, по которой я буду писать ядро. Подчеркиваю, из старого я планирую оставить только логику чтения пакетов (селектор и прочую муть) и их криптографию. Ну и базовые геометрические классы. Все остальное нульцево

Добавлено через 3 минуты
Даже если к тому времени как линейка полностью загнется, хоть будет код на который будет приятно смотреть) к тому же все публичные методы я понятно комментирую. Будет как пособие начинающим) ибо сам программировать начал года 3 - 4 назад благодаря линейке ^^

[KID]

krisadr, не смог применить ваши слова

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

к моему посту, поэтому посчитаю что вы неверно прочитали/трактовали мое сообщение.
к тому же для одного программиста что-то логично, а для второго - нет. Вот видно начинающего программиста с багажом энтузиазма и романтики

ProDev, отрефакторить фундамент, не перестроив с чистого листа все этажи - нельзя. люди, ищущие выгоду из этого код-продукта возьмутся за такое дело в очень редких случаях

[shegan]

Боюсь, что все упрется в рефакторинг. Посмотрите любой код (что l2j, что оверов и код поверх них) - сервисного слоя как такового нет - логика распихана (по-другому не скажешь) везде, от пакетов до модели. То есть что-то происходит в пакетах (в том числе и DAO, которого, как отдельной сущности, не существует), и в модели (см. Player/L2PcInstance), и еще где-то. Как следствие, связанность кода зашкаливает, рефакторинг превращается в целое приключение. Добавим сюда использование Reflection + Concatenation и эти бессмысленные на 90% скрипты - все, отрефакторить что-то становится целым приключением. Ваша IDE банально не увидит некоторые зависимости и проблемы начнутся уже на простом rename/move. Я думаю, это причина №1 движения по накатанной. Из всего, что я видел, только команда JTS, которая продавала код HF отдельно, пошла по правильному пути и развязала этот узел (хотя бы судя по структуре проекта, но, думаю, где-то так оно и есть).

Разрешите узнать, что такое "Reflection + Concatenation"?

[krisadr]

Читай динамическое программирование. Кратко написание кода во времени выполнения

[ProDev]

Применительно к тому же коду оверов я говорил, например, о ситуации, когда есть некий класс MyNpcInstance, прямых референсов на него нет. Да и лежит он в скриптах. В XML с описанием NPC есть параметр типа type="MyNpc". По факту он используется как:

Код:

String class = "com.foo.bar" + npcTemplate.getType() + "Instance"

И далее уже создание инстанса через Reflection.

По поиску MyNpcInstance вы не найдете ни одного использования в коде. Отследить такое, скажем, маловероятно. Не зная всех таких подводных камней, можно наломать дров.

[krisadr]

Лучше вообще таких камней не делать без надобности. А я сомневаюсь в их надобности) Единственное где я использовал .class так это в логгере

[pchayka]

Если так не нравится видеть в коде запросы БД - переведите все в тот же hibernate или хотя бы переработайте всю логику запросов в процедуры. Будет у вас в коде простой и чистый вызов процедурки с параметрами. Изобретать заменители БД тут малополезно.

[shegan]

Применительно к тому же коду оверов я говорил, например, о ситуации, когда есть некий класс MyNpcInstance, прямых референсов на него нет. Да и лежит он в скриптах. В XML с описанием NPC есть параметр типа type="MyNpc". По факту он используется как:

Код:

String class = "com.foo.bar" + npcTemplate.getType() + "Instance"

И далее уже создание инстанса через Reflection.

По поиску MyNpcInstance вы не найдете ни одного использования в коде. Отследить такое, скажем, маловероятно. Не зная всех таких подводных камней, можно наломать дров.

А, ну я всегда знал другое название этому - говнокод.
Для инстанцирования таких вещей нужны фабрики какие-нибудь, или подобный подход.

Добавлено через 7 минут

Если так не нравится видеть в коде запросы БД - переведите все в тот же hibernate или хотя бы переработайте всю логику запросов в процедуры. Будет у вас в коде простой и чистый вызов процедурки с параметрами. Изобретать заменители БД тут малополезно.

И не обязательно даже Хибернейт тащить, достаточно маленькой ORM какой-нибудь, Ebean, например.
Или самому упростить представления объекты для его персистентности, написать свой механизм подобный ORM.
Но мне кажется тут дело совсем не в этом и это не очень подойдет.
Если уж встает вопрос о проблеме использования/поддержки RDB, то приготовить ORM - будет ещё сложнее.
Да и она медленее работает (уж хибернейт, по сравнению с mysql, точно).

[Zubastic]

Автор, зачем Вам C# если на java можно также работать с формами?

[Respect]

Не по теме

Я тут столько прочитал умных слов, но когда прошу сделать логин сервер на ++ для UE4 все бегут=)