Основы ООП (вопрос по книге "Head First Java")

а как там сами классы называются? надо ли делить на классы? - да Лучше - больше классов? - да. лучше больше маленьких и понятных, чем меньше, но огромных и в которых черт ногу сломит Как выбрать нужное количество? - никак. ты не знаешь заранее сколько классов тебе понадобится Чем руководствоваться при их создании? - принципами ООП По какой логике? - вот это самый интересный вопрос. в ООП один из принципов называется абстракция. каждый понимает как хочет, конечно, но я это понимаю так, что перед тем, как садиться и пилить код - надо перед этим подумать. подумать на какие элементы разбить твою программу, что в ней будет использоваться... и что наверное самое важное - производить такую разбивку ориентируясь на объекты реального мира (ну или доменной области). например, в морском бое логично, что будет какое-то "поле" и будут какие-то "кораблики". причем корабликов будет уйма просто, а вот игровых полей будет столько, сколько у тебя игроков (у каждого игрока ведь свое поле будет). соответственно вот тебе уже 2 класса. еще ооочень важный принцип, это чтобы каждый класс отвечал за свою часть работы. например игровое поле - не должно "стрелять" по вражескому полю, оно не должно выводить какие-то надписи на экран, оно должно просто содержать кораблики. игровая логика должна быть вынесена в другие классы (собственно в классы с игровой логикой). в общем, старайтесь чтобы ваши классы (объекты ваших классов) выполняли только свою работу. зачем - поймете когда в уже рабочую программу морского боя захотите внести какие-то изменения (у меня так и было, когда я в один момент решил что неплохо было бы поиграть не против компа, а поиграть человек против человека, или наоборот посмотреть как будут два компа бороться, или если захотите сделать разные уровни сложности компов, с которыми будете играть и еще куча возможных изменений). если же все писать в одном классе (а еще лучше - все прям в main-е) - вы возненавидите программирование))

Возможно, меня поправят, но, как мне кажется, это сделано для удобства. Допустим, что код пишут десяток программистов и он состоит из тысяч строк. Как им организовать работу? А так получается, что один пишет один функционал, другой пишет другой функционал, потом все эти файлы-классы собирают в одну папку, пишут общий main и прога работает. Да даже при одиночной разработке это крайне удобное решение. Если тебе нужно поправить, допустим, кнопку на панели в приложении, зачем тебе лезть в код с алгоритмом работы приложения? Заходишь в класс с формой и меняешь всё, что нужно. Или если работа над проектом переходит к другому человеку. Ты знаешь структуру проекта и можешь там что-то откопать, а новый человек, будь все классы написаны в одном файле, получил бы геморрой в виде разбора всего огромного кода. А ему надо было всего-то поменять букву в каком-нибудь выводе. ООП в целом подразумевает, что объекты и методы выполняют определенный ограниченный набор функций. Потому каждый класс суют в разный файл. Чтоб без проблем корректировать работу определенных частей программы. На истину в первой инстанции не претендую. Это исключительно мое представление о языке.