LINUX.ORG.RU

История изменений

Исправление Legioner, (текущая версия) :

По геттерам-сеттерам. Проблема в неоднородности кода. В каких-то местах ты точно захочешь иметь геттеры-сеттеры. Если у тебя будет половина так, а половина по-другому, то это будет плохо читаться. Лучше пусть везде будут геттеры-сеттеры. Это нахаляву даёт возможность изменять их поведение в будущем и ставить быстрые брякпоинты на изменение данных (Ты можешь поставить брякпоинт на геттер, чтобы узнать, кто читает это поле или ты можешь поставить брякпоинт на сеттер, чтобы узнать, кто пишет в это поле. Есть возможность ставить брякпоинт прямо на доступ к полю, но он замедляет программу).

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

Про List. Ты придираешься к мелочам. Я тебе советую почаще использовать встроенные массивы, если тебе не нужно изменение размера, там можно индексировать оператором. List как правило индексировать не нужно. Ну а если нужно, не такая это и проблема.

Исходная версия Legioner, :

По геттерам-сеттерам. Проблема в неоднородности кода. В каких-то местах ты точно захочешь иметь геттеры-сеттеры. Если у тебя будет половина так, а половина по-другому, то это будет плохо читаться. Лучше пусть везде будут геттеры-сеттеры. Это нахаляву даёт возможность изменять их поведение в будущем и ставить быстрые брякпоинты на изменение данных (Ты можешь поставить брякпоинт на геттер, чтобы узнать, кто читает это поле или ты можешь поставить брякпоинт на сеттер, чтобы узнать, кто пишет в это поле. Есть возможность ставить брякпоинт прямо на доступ к полю, но он замедляет программу).

Суммируя — проблем с их генерацией нет и они дают незначительные удобства.

Про List. Ты придираешься к мелочам. Я тебе советую почаще использовать встроенные массивы, если тебе не нужно изменение размера, там можно индексировать оператором. List как правило индексировать не нужно. Ну а если нужно, не такая это и проблема.