>>888541 (OP)
http://gans-spb.livejournal.com/33248.html

>>888541 (OP)
Ленивое ты хуйло, иди гугли "кники по ООП".
Ты как будто какой-то особенный, что перед тобой должны распинаться успешный аноны-девелоперы.

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

Это все от того, что ты как раз таки и делаешь кошечек да собачек. А если начнешь пилить нечто более-менее реальное то сразу же поймешь в чем суть, базарю.
>>888715
Опять же примитивное объяснение. Лучше суть ООП показать на примере сравнения станка и разбросанных инструментов. Вот ты можешь делать что-то просто инструментами, которых дохуя и они везде валяются, а можешь делать на станке, где все эти инструменты удобно сложены внутри оного(инкапсулированы), а ты просто делаешь нужный рычаг(метод) и станок сам все делает.

>>888715
П — Полиформизм

>>888541 (OP)
Вот, покури.
http://www.carlopescio.com/2012/03/life-without-controller-case-1.html
В трех частях описывается как пользуясь мозгом и ООП из говнокода можно сделать программу.

>>888715
Проиграл

>>888541 (OP)
https://m.geektimes.ru/post/148134/

>>888541 (OP)
Для «объекта» не существует формального определения. ООП вообще никак не формализовано. Это набор ad hoc практик, интуиций и советов бывалых охотников в стиле «чтобы копье лучше било мамонта, его должна обоссать девственица в полнолуние».

>>889568
>geektimes
>m
Что это там за вскукарек из-под шконки раздался?

>>888715
Ну это уже пиздец.

Мы создаем интерефйс ГовноКотороеДвижетсяИЖретЧтоТо, в этом интерефейсе есть методы покормить(на вход идет тип ресурса и колияество, если ресурс не подоходит он пошлет тебя нахуй) и переместиться.

И пилим кошку и машину которые его ревлизовывают.
А пилим мы игру, забыл сказать. И у нас в игре есть кошки и машины. И вот игрок взял в руки рыбу и подошел к какому-то объекту, который точно реализовывает этот наш интерфейс, это 100%, нам это гарантируется. Вообще хз что это за объект, может самолет, а может кошка, а может машина. Ну игрок и обращается к этому объекту - "на попробуй сожрать рыбу, хули делать то". И в зависимости от класса этого объекта будет разная реакция.
Ты скажешь - а можно сделать переменную тип объекта и просто проверку типа делать и реакцию в зависимости от этого. Можно, ты прав, но это не удобно.

>>889580
Хуйню сказал.
ООП очень строго формализовано. Просто в учебниках это никак не могут пояснить, зацикливаясь на котиках.

Обычные структуры данных - это простые хранилища данных. Просто публичный склад, куда может заглянуть любой и поменять что угодно. Массивы переменных разного типа.
Обьекты - это структуры данных, реализующие какое-то поведение. Т.е. информация + поведение.

Эта разница имеет ключевую роль, и мало где обьясняется.

Например представь себе структуру из двух массивов (А и Б), где один(Б) ссылается на элементы другого(А).
Для этой структуры ты подразумеваешь какое-то поведение, например что массив Б всегда имеет валидные данные.
Зачем такое поведение? Ну например тебе было бы удобнее, если голова за валидность массива Б перестала бы болеть, если бы ты всегда был уверен в массиве Б.

Обычная структура не может обеспечить поведение - ты можешь спокойно стереть массив А, и массив Б будет невалиден. Т.е. тебе придется поддерживать валидность массива Б где-то за пределами структуры, например перед доступом к массиву Б сперва проверять его валидность(хотя бы на нулл).

Обьект может обеспечить такое поведение.
Но для этому ему важно контролировать доступ, т.е. массив А не может быть публичным, иначе массиву Б нельзя гарантировать валидность. Так работает инкапсуляция - она вынужденная, и диктуется поведением, которое мы ожидаем от обьекта.
Обьект берет всю заботу о поддержании поведения данных на себя: перед доступом к массиву А, обьект проверяет доступ на безопасность, убеждается что массив Б при таком доступе останется валидным, иначе запрещает доступ.
Более того, массив Б будет валиден в любой момент жизненного цикла обьекта: обьект при создании инициализирует массивы дефолтными данными, либо берет данные снаружи. Массив Б можно не проверять снаружи - если обьект вообще существует (а вот это проверять можно и нужно), обьект гарантирует валидность массива Б.
Т.е. обьект просто реализует то поведение, которое мы хотели: гарантирует валидность массива Б.
Обьект реализует поведение через инкапсуляцию - он запрещает доступ к массиву А, и контролирует его(доступ), предоставляя свои методы доступа, с проверками, геттеры и сеттеры.


В учебниках хуйня, потому что обьясняют ООП на обьектах реального мира. А ООП к реальному миру имеет отношения чуть менее чем нихуя.
ООП - сущность мира информации, и имеет смысл только относительно информации.
Вот эту вот разницу трудно понять - после учебников тянет пилить структуру обьектов как ИРЛ, и выходит лютая хуета, никак не стыкующаяся с данными.
Обьекты можно пилить только под конкретные данные и конкретные требования к ним, предьявляемые здесь и сейчас (в этом месте архитектуры системы).
Т.е. поведение обьекта определяется не хотелками и перделками, не аналогиями с кошечками, а архитектурой системы и местоположения данных в ней, окружения этих данных.
Где-то достаточно простой структуры данных и никакого поведения не требуется, где-то достаточно просто обеспечить корректность, где-то нужно поддерживать корректность огромной связной структуры, да еще и реагировать на дюжину сигналов в зависимости от содержания этих данных.

Т.е. ООП - это в первую очередь инкапсуляция. А если быть точнее, ООП это реализация поведения у данных, что без инкапсуляции невозможно.
Ну а полиморфизм, наследование и абстракция - лишь необязательное дополнение к ООП, упрощающее жизнь, сокращающие размер кода, увеличивающие степень реюза кода.
Полиморфизм позволяет несколько похожих обьектов склеить в один, перегрузив методы доступа, и обеспечив единый интерфейс к нескольким похожим обьектам.
Наследование - собрать в обьект общее поведение и данные нескольких различающихся обьектов, снаружи реализуя лишь разницу.
Абстракция - отделить ключевые особенности обьекта от остальных, т.е. провести границу: где обьект, а где наследники.

Понимая что для чего и комбинируя все это, проектирование системы значительно упрощается, получаем минимум кода, простую и логичную архитектуру, высокую изоляцию обьектов ==> высокую надежность и малую связность обьектов ==> легкую модификацию архитектуры, а отсюда опять же автоматический реюз кода: при любых изменениях затрагивается лишь малая внешняя часть архитектуры, все остальное продолжает переиспользоваться.
Ну а если нет понимания хотя бы одного компонента (или даже инструмента ООП) - проектирование значительно усложняется, т.к. приходится лепить много костылей чтобы обеспечить то, что ООП и так может обеспечить, но непонятно как этого добиться, непонятно когда, как и какой инструмент использовать.