ООП и с чем его едят?
Публичный постПривет Клуб
Сегодня хотел поговорить на тему объектно-ориентированное программирование. Сколько языков программирования не учил(ну да, приходилось учить большое количество), то всегда было сложно с восприятием данной парадигмы программирования
Вопрос
Кто может посоветовать или рассказать, зачем оно, привел примеры из настоящих примеров, а не вот это:
Представлением объекта является класс. Класс фактически представляет определение объекта. А объект является конкретным воплощением класса. Например, у всех есть некоторое представление о машине, например, кузов, четыре колеса, руль и т.д. - некоторый общий набор харакстеристик, присущих каждой машине. Это представление фактически и является классом. При этом есть разные машины, у которых отличается форма кузова, какие-то другие детали, то есть есть конкретные воплощения этого класса, конкретные объекты или экземпляры класса.
Окей, люблю объяснять что-нибудь на пальцах. Совсем по-простому, колхозно. Я специально опущу всякие паттерны и прочее (для тех, кто увидит пересечение с терминами :)) )
Что там ещё..? Абстрактный класс? Ну, сидушка есть, а ножки каждый сам накорячит, как хочет. Вдруг ты захочешь венский стул или телескопические? Сидеть на сидушке, как на стуле, низя, значит только брать и делать своё (абстрактный класс не может иметь инстансов без наследования) :)
Как-то так.
Зачем всё это? KISS, DRY, SOLID и прочие страшные слова, которые говорят только об одном: пиши так, чтобы то, что ты пишешь, можно было потом переиспользовать где-то ещё без тотального кровьКишкиПереписываниеДедлайн. Реальный мир представлен нам в форме объектов, поэтому, описывая нечто текстом, мы можем декомпозировать это так, чтобы оно подходило целому пулу систем в виртуальном :)
ООП едят с большими проектами. Оно нужно для структуризации кода, разделения на такие части, каждую из которых можно охватить умом за раз.
Если проект на 1000 строк, то написать его довольно просто практически в любой парадигме, но писать реально большие системы без ООП могут только скилловые функциональщики, да и то скорее всего там две парадигмы довольно сильно пересекаются.
Собственно, к чему я все это - нужно просто брать и писать крупные системы (не обязательно что получится, главное сам факт), и понимание ООП просто придёт само.
А сейчас, наверное, просто не ясно зачем это всё, и дело не в том что аналогии непонятные, а в том что нет связи "причём тут вся эта мутотень и живой код чтобы кнопочка нажималась", это решается опытом.
P. s. Мне помогало в изучении, когда в школьные годы я замахивался на проекты сильно выше головы - большие игры, большие веб приложения. Ничего такого даже близко не мог написать, но пока искренне пытался (невежество не давало осознать истинную сложность задачи) - очень многое понимал в процессе.
Если честно, кроме книжки про паттерны ничего в голову не приходит. Там Java и паттерны с примерами применения. Мне она показалась не особо полезной, но я нахожу объектно ориентированный дизайн интуитивно понятным и легко могу спроектировать любое приложение на уровне заменяемых блоков.
Скорее всего книжками прокачать ООП не получится, нужна практика.
Я почти не имею опыта работы с Java, но знаю что C# построен на единой иерархии типов. По нему довольно легко понять как примерно все это должно работать. Стоит посмотреть на .NET классы, интерфейсы и попробовать сделать что-нибудь свое.
😱 Комментарий удален его автором...
В книге Head First Object Analysis and Design вполне доходчивое объяснение принципов ООП с примерами. Единственное, в книге сделан акцент на Java (хотя мне кажется это не критично).
https://www.coursera.org/learn/programming-languages-part-c - очень толковый разбор что за классы такие и зачем нужны, для лучшего понимания желательно пройти предыдущие две части, оно того стоит
Что тут важно понять прежде всего не что, а для чего: ООП - это просто один из способов структурировать код.
Структурируя код, мы преодолеваем сложность системы; мы представляем ее в виде слоев абстракций, каждая из которых не слишком сложна. Для этого нам нужно как-то спрятать ненужные в каждом конкретном слое детали. Здесь нам поможет инкапсуляция.
Вторая, не менее важная задача - постараться написать как можно меньше кода; для этого его нужно использовать повторно. Здесь нам поможет полиморфизм.
Я думаю, все хорошо понимают, что такое модуль: вот у нас объявлены какие-то переменные и какие-то функции в нем, мы можем вызывать функции, которые эти переменные как-то используют или меняют; совокупность состояний всех переменных модуля можно назвать состоянием модуля. Так вот: объект - это когда состояние модуля можно сохранить в отдельную переменную, а также передавать в качестве аргумента в функцию или возвращать из функции. Сам же такой модуль (в отрыве от состояния) мы можем с известной натяжкой назвать классом. Можно также сказать, что класс - это тип конкретного объекта.
Теперь мы можем скрыть внутри объекта ненужные нам детали реализации (в том числе и другие объекты), определяя максимально простой контракт для заданного уровня абстракции.
Вторая задача решается через организацию типов в иерархию таким образом, чтобы всякий раз можно было бы использовать менее абстрактный тип там, где контракт определяет более абстрактный. Например, если функция "нарисовать" принимает класс "фигура" в качестве аргумента, а классы "круг" и "квадрат" являются подклассами класса "фигура" - то в функцию можно передать как круг, так и квадрат.
Да отведет судьба от меня гнилые помидоры!
Прежде всего попробуй разобраться что такое и для чего нужны инкапсуляция и полиморфизм. Это ключевые понятия ООП. Наследование это исклбчительно способ реализации полиморфизма, наследование это про систему типов, способ ее построить.
Потом почитай вот этот пост Фаулера про Tell, son't ask.
Потом посмотри как все эти очень умные советы можно воплотить в жизнь, потому что это нифига не очевидно.
Это есть вот тут:
И в блоге Егора Бугаенко. (Но упаси тебя боже читать там что-то на другие темы).
А я может пост наваяю а то писал коммент, а получилось уже дофига.
Как писал старина МакКонел: «Главный Технический Императив Разработки ПО - управление сложностью»
Человек не может помнить всё, в институте нас учили, что продавец на память может "вспомнить" что-то порядка 1000 позиций.
ООП помогает во-первых, увеличить количество абстракций, тем самым снизить количество сущностей задействованых в операции, и во-вторых, структурировать код. И то и другое благотворно сказывается на когнитивных затратах и экономии мыслетоплива.