Всем добра. Допустим мне нужно создать программу для учета живности на ферме. Куры, коровы, быки, лошади, поросята. Я правильно понимаю у меня будет родительский класс для всех с названием Животное и с параметрами(дата рождения, пол, вес, дата смерти). От него будут подчиненные классы -
КРС(крупный рогатый скот) и у него будут параметры - сколько молока дает)
Куры с параметрами - сколько яиц дает
Лошади - сколько молока дает
Поросята - тут даж не знаю.
В общем я запутался, вроде бы можно всего лишь создать один класс Животное с параметрами др, пол, вес, дата смерти и еще к нем добавить атрибуты количество молока, яиц и не заморачиваться созданием субклассов. В общем я запутался( наверное не ферме не стоит применять ООП?) собаки тож есть, но их доить вроде не будем и мяса не дают они(
lutokris , хорошо, ты хочешь использовать ООП для реализации ПО учета активов фермы.
Какие составные элементы ОО-подхода ты знаешь? Изложи коротко их суть.
Обрати внимание на то, что уже написанные ответы не учитывают заданный мной вопрос. Возможно, это может что-то означать.
Я бы сделал 1 или 2 класса, которые бы отображали то что есть на ферме. Как я вижу, Куры, Лошади, Поросята, ... это данные а не обязательно классы которые должны быть в програме.
Исходя из задания которое ты написал, а именно (хранение/получение информации) то есть, тебе нужно просто хранить данные, достаточно использовать коллекции для этого, ты можешь хранить животных в списке как объекты, а можешь просто как элементы. В дальнейшем если тебе понадобиться добавить методы животным, то ты без проблем это сможешь сделать. Тут можно остановиться на простой иерархии. Dogs extends Animal, Cat extends Animal, etc..
я правильно понимаю, что самая главная задача ООП - она должна упрощать разработку сложной длинной программы и ее изменение, обновление. И в моем случае когда нужно лишь вести контроль поголовья, экономические расходы и доходы, наверное проще будет без объектов. База данных, структуры, функции для доступа, вывода, вычислений - этого думаю хватит.
В общем и целом, ООП держится на 3 китах: инкапсуляция, полиморфизм, наследование.
Тут согласен с некоторыми на счет, что ООП хорошо будет для создания мини игры про ферму.
Создаем базовый класс животные. Наследуемые классы корова, свинья и т.д. Это будет проявлением наследования. Причем наследование м/б разное в зависимости от уровня доступа данных.
Как тут кто-то написал "сделаете в базовом классе методы типа «гулять», «давать урожай», «подавать голос» и прочее, а реализацию сделаете разную у каждого." Это будет полиморфизм.
Ну а инкапсуляция это такая вещь, тут в двух словах не опишешь. В общем и целом, защита информации. Когда к данным есть доступ в самом классе, или через методы описанные в классе. То есть вне класса напрямую нельзя обращаться к данным.
Это мое понимание. Возможно оно различается с пониманием людей, у которых больше опыт.
Saboteur, А как вы понимаете инкапсуляцию?
Конечно, без наследования и полиморфизма было бы много дублирования, это понятно.
Но почему причина в инкапсуляции?
Смысл ООП заключается в том, чтобы все функции(методы) для работы с данными находились внутри класса, где находятся эти данные.
В этом случае очень легко соблюдать версионирование и совместимость между разными частями программы, потому что если что-то меняешь в одном классе, то ты легко изолируешь все изменения - ведь другие классы обращаются не напрямую, а через методы.
В этом и заключается преимущество ООП для разработки крупных проектов большим количеством людей.
Любая аналогия имеет границы, хочешь в ооп? Напиши любую фиговину в структурном стиле, а потом начни ее развивать. Когда перестанешь понимать что ты вообще пишешь, и плодить баги быстрее чем фиксить - начнешь понимать методы управления сложностью(включая ооп), или не начнешь...
Это точно.
Ты сейчас разбираешь структуры данных, а ООП это больше про методы и инкапсуляцию.
Чтобы делать учет животных вообще не обязательно для них класс делать, храни все в базе, учет веди sql запросами, например.
P.S.
собаки тож есть, но их доить вроде не будем и мяса не дают они(
ООП применимо в любой задаче, и да, в очень простых задачах оно может быть избыточно. Объекты ООП имеют мало отношения к реальному миру, это чисто техническая реализация, соответственно исходить нужно из технических требований в первую очередь, а не из биологической классификации видов.
Из вопроса абсолютно не ясно, каковы требования. Вполне возможно что вам достаточно объектов учета, каждый объект это как строчка в книге учета. В зависимости от использования, возможно понадобятся объекты ресурсы даваемые объектами учета. Но все это зависит от предъявляемых требований.
