Я отвечу на ваш вопрос в трех частях:
1. Прямой доступ (публичные участники) является наихудшим решением:
Доступ к публичному члену извне класса, что для практических соображений означает «потенциально где угодно». Если что-то пойдет не так с публичным полем, виновник может быть где угодно, и поэтому, чтобы отследить ошибку, вам, возможно, придется посмотреть довольно много кода.
2. Инкапсуляция (частные члены):
Личный член, напротив, может быть доступен только изнутри одного и того же класса, поэтому, если что-то пойдет не так, обычно есть только один исходный файл. Если у вас миллион строк кода в вашем проекте, но ваши классы невелики, это может уменьшить ваши усилия по отслеживанию ошибок в 1000 раз.
3. Getters and Setters сильно злоупотребляют:
Создание частных полей, а затем использование IDE для автоматической генерации геттеров и сеттеров для всех этих полей почти так же плохо, как использование открытых полей.
Одна из причин поскольку чрезмерное использование заключается в том, что в среде IDE это всего лишь несколько кликов для создания этих аксессуаров. Совершенно бессмысленный код getter / setter временами дольше, чем реальная логика в классе, и вы будете читать эти функции много раз, даже если вы этого не хотите.
ЗАКЛЮЧЕНИЕ:
Использование аксессуаров (геттеров и сеттеров) для ограничения прямого доступа к переменной поля предпочтительнее использования публичных полей, однако создание геттеров и сеттер для каждого поля является излишним. Это также зависит от ситуации, хотя иногда вам просто нужен немой объект данных. Аксессуаров следует добавлять в поле, где они действительно требуются. Класс должен выставлять большее поведение, которое используется для использования его состояния, а не для хранилища состояний, которое должно обрабатываться другими классами.
В коде есть два цикла «выполнения», поэтому он никогда не попадает во второй цикл.
Отступы в коде перепутаны - может быть, из-за вставки в SO? Подавляющее большинство программистов используют 4 пробела для отступа. Это, вероятно, хороший обычай для подражания.
Код также загружал «стартовое» изображение при каждой итерации цикла, в этом нет необходимости (если только он не изменяется на диске, в этом случае используйте os.stat()
для проверки изменений перед его повторной загрузкой).
Переработанный основной цикл:
folder = os.path.dirname(os.path.realpath(__file__))
start = pygame.image.load(os.path.join(folder, "wecvguh.png"))
run = True
while run:
for event in pygame.event.get():
if event.type == pygame.QUIT:
run = False
if event.type == pygame.KEYDOWN:
command = "python AhjaiyCPT.py"
subprocess.call(command)
gameDisplay.fill(white)
gameDisplay.blit(start, (x,y))
pygame.display.update()
pygame.quit()