Я не до конца понимаю ООП, что мне надо знать?

Хочу для своей будущей работы программистом реально быть полезным бизнесу и для этого я в процессе обучения C# хочу понять где применяется ООП и почему? И зачем он нужен? Приведу пример почему я это спрашиваю, вот например есть у нас скажем так личный кабинет, в котором отображена информация ну например: ФИО, адрес к аватарке, эл. почта. И какой смысл тут создавать класс? давать типы для полей, делать его закрытым или открытым? В каких реальных случаях может пригодиться создание класса для проекта? Приведите пожалуйста примеры, у меня не получается запоминать то, в чем я не вижу перспективу реального применения.
  • Вопрос задан
  • 7053 просмотра
Решения вопроса 1
@Stqs
senior software developer
на вашем примере конечно сложно аргументировать зачем нужно ооп
но все это действительно связано с управлением сложностью и разработкой более менее больших систем

проблема в том что мозг устроен так, что ему сложно держать в голове одновременно(объем внимания) больше 7-10 объектов
есть конечно уникалы, да и программирование вцелом этот скил конечно развивает но если брать среднего обычного человека то это действительно так.
Как пример - попробуйте решить задачку Эйнштейна в голове Ж) Там нет ничего сложного но нужно одновременно держать пару десятков кусочков информации в голове. БОльшинство людей это не в состоянии сделать.
По этой же причине:
- на рекламных плакатах вы не увидите длинных текстов - 5-7 слов максимум
- функция из 10-20 строк легче воспринимается чем из 100-200 строк,
- 5-7 аргументов функции легче осилить чем 27
- 5-7 переменных в функции легче удержать в голове чем 20
и тд и тп

Проблема особенно актуальна в программировании
Вы можете написать функцию как и хотели. все ок. претензий нет.
вы напишете еще 10 функций и еще сможете понимать что там написано
но что если их будет 100? 1000?
Вы сможете так же быстро разбираться в том что происходит в программе? особенно после полугода перерыва например
отсюда возник вполне естественный верхний потолок для размера программ - больше просто нереально было поддерживать. Нереально удержать в голове даже командой
Написание кода таким способом очень плохо масштабируется

ежели вы применяете ооп то каждый класс можно рассматривать как отдельную сущность у которой относительно небольшое количество полей/методов. то есть во-первых их теперь можно вместить в голову не принимая во внимание тонны окружающего кода, во-вторых, что самое главное, их и не нужно вмещать в голову потому что ты теперь вместо 100 функций в голове держишь картинку из 7 классов, что очень легко
если нужно знать реализацию конкретной сущности - идешь и читаешь - она гарантированно поместится в голову
вы можете сказать но у меня в программе может появится 100 классов или 1000 классов, что тогда? тут на помощь приходит абстрагирование
скорее всего многие из этих 100 классов входят в какие-то(возможно абстрактные) структуры более высокого порядка, поэтому хоть классов у вас и 100 - работа с ними может быть облегчена введением классов на следующем, более высоком уровне абстракции которые работают с классами более нижнего уровня абстракции, таким образом вы опять работаете с те ми же 10 сущностями, которые отлично помещаются в голову
это все приводит к тому что теоретически, программа на опп масштабируется бесконечно
теряешь контроль над сложностью - абстрагируешься
интересуют детали - опускаешься на нужный уровень и изучаешь как конкретный класс работает
не говоря уже о бонусах которые ты получаешь имея наследование, полиморфизм и собственно инкапсуляцию

ну и еще плюсом можно назвать то что ООП все-таки более подходит для описания того что происходит вокруг
если мы посмотрим вокруг то все что мы видим - объекты, с какой-то внутренней сложной структурой
мы явно можем эти объекты группировать(классы) - люди, компьютеры, машины
мы видим что эти объекты могут взаимодействовать друг с другом через определенный интерфейс, и их совершенно не интересует как конкретный объект устроен внутри(инкапсуляция)
то есть при ооп работа сводится к тому что бы выделить сущности которыми ты реально будет оперировать в своей программе, определить интерфейс(как они могут взаимодействовать. А дальше лишь описывать эти взаимодейсвтия. При этом вам нет необходимости держать в поле зрения все имеющиеся классы, их методы, поля, всю логику их поведения и взаимодействия,
Ответ написан
Пригласить эксперта
Ответы на вопрос 11
search
@search
Мой дедушка индиго
Для того чтоб быть полезным бизнесу посмотрите в сторону Domain Driven Design. Это как раз про энтерпрайз и ООП программирование. Есть очень полезная (и бесплатная) книга Domain Driven Design quickly https://www.infoq.com/minibooks/domain-driven-desi... . Она около 100 страниц. Что немаловажно, после прочтения, вы начнёте видеть смысл в структуре современных фреймворков.

Еще очень важно выучить наизусть принципы SOLID. Это про грамотную организацию ООП кода. Повторюсь, нужно знать их наизусть. Ну и желательно, но на первых порах не обязательно, понимать.

Когда вы разберетесь с DDD, SOLID и прочими паттернами проектирования (кстати "Шаблоны проектирования" https://www.ozon.ru/context/detail/id/2457392/ - это тоже мастрид), вас ослепит и оглушит возможность писать очень гибкий код. Настолько оглушит, что вы перестанете слушать требования заказчика и вчитываться в спеки. Такой подход называется "супергибгая архитуктура", и это болезнь людей, которые занимаются ООП первые годы и немного осилили это дело. От этой болезни есть лекарство, - принцип YAGNI. Его тоже нужно выучить наизусть. Он не только в программировании полезен, но и в жизни.

К сожалению, одним комментарием невозможно объяснит что это такое и с чем это едят, потому что если бы это было возможно, то на земле настал бы рай. Сам процесс занимает несколько лет и, будучи C# программистом вы рано или поздно придёте к осмысленному написанию классов и использованию объектов. С книгами и принципами это будет быстрее. Подытожу то что было сказано выше
  • Книга Design Patterns поможет увидеть примеры грамотного использования ООП
  • Книга DDD quickly (а желательно полная версия DDD, которая на много сотен страниц) поможет с организацией архитектуры приложений,
  • Принципы SOLID помогут в написании кода, за который не будет стыдно перед коллегами, а принцип YAGNI поможет в написании кода, за который не будет стыдно перед собой.


Успехов!
Ответ написан
MedVedar
@MedVedar
wp developer
ООП это лишь организация кода. Не хочешь - не пиши так. Но ты уверен, что сможешь сразу разобраться в своем лапшкекоде, когда откроешь его через пару месяцев спустя? А если нужно подключить к разработке другого человека?
Ответ написан
Я бы тогда порекомендовал две книги
Стив Макконел - Совершенный код.
Роберт Мартин - Чистая архитектура.
Все очень классно расписано. С примерами, пояснениями и тд.
И наверное еще бы Чистый код, тоже Роберт Мартин, это в догонку.
Ответ написан
@justhabrauser
"Я не до конца понимаю ООП"
Иэх.. "я не до конца понимаю"...
Диоген удавился бы со своим "я знаю, что ничего не знаю".

Лучше начать с машинных кодов.
Потом - Ассемблер
Потом - C
Потом - Страуструп и C++
Ну а дальше можно и ООП.
Ответ написан
@HellWalk
Я не до конца понимаю ООП

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

В этом плане очень показательно это видео:
https://www.youtube.com/watch?v=lfdAwl3-X_c
Где в комментариях также масса несогласных.

Ну а теперь по пунктам:
где применяется ООП и почему? И зачем он нужен?

Где - практически везде. Считается, что на нем разрабатывать и поддерживать код проще.

И какой смысл тут создавать класс?

В ООП все, или почти все, рассматривается как объекты.
Соответственно вопрос нужно ставить по другому: Как правильно разделить функционал на сущности (объекты), и как правильно между ними сделать взаимодействие.

давать типы для полей, делать его закрытым или открытым?

По умолчанию закрывайте все. А открывайте только то, что должно быть открытым (т.е. то, что используется снаружи)
Ответ написан
ksenofobius
@ksenofobius
Люблю долбить по клавишам
Если в кратце, ООП сделает ваш код значительно более читабельным и расширяемым. Код написанный на ФП сложнее поддерживать. ООП позволяет работать с абстракциями, вам не нужно знать детали вызывай тот или иной метод.
Например в вашем случае есть юзер с ФИО, адрес к аватарке, почта. Например в лк вам нужно вывести Фамилия И.О инициалами. Работает с классом вы можете реализовать метод getShortName который возвращает к примеру 'Петров П.И.', и этот метод относится только к сущности пользователя. Все это позволяет инкапуслировать логику внутри класса, в коде вам не нужно каждый раз вызывать функцию типа getShortNameFrom(user) или еще хуже getShortName(firstName, lastName, patronymic). Инкапсуляция позволяет вам избавить других программистов (и вас в будущем) от желания напрямую вытащить приватные атрибуты.

Другой юзкейс это полиморфизм. Представьте что у вас есть класс Sqr, Rect, Triangle. Для того чтобы посчитать площадь вы можете просто вызвать методы sqr.calcaulateArea(), rect,calculateArea(), triangle.calculateArea(). Без ооп это выглядело бы так
calculateArea(w, h) // квадрат
calculateArea(r) //круг
И это в случае если у вас есть возможность перегрузки функций, если ее нет (как например в го) вам нужно называть каждую функцию так:
calculateRectArea(w, h) // квадрат
calculateSqrArea(r) //круг

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

Ну и последнее это наследование. Опять по примеру вашего случая, есть у вас пользователь, и он не может ничего редактировать (у него нет прав). Однако у вас есть ряд модераторов которые могут править данные в личном кабинете (и этот администратор также обладает полем ФИО, аватар и т.д, за тем исключением что вам нужно как-то добавить саму возможность редактирования)
В этом случае вы можете унаследовать класс модератор от обычного пользователя, таким образом он будет обладать всеми стандартными полями (и вам не придется писать их 2 раз => кода будет меньше) и правами на редактирование.
(псевдокод)
class User
    private firstName: string;
    private lastName: string;
    private patronymic: string;
    private avatarPath: string;
    private email: string;

class Moderator(User)
    private moderatedSections: []string
Ответ написан
BacCM
@BacCM
C++ почти с рождения
Если будет класс Пользователь. То личный кабинет у него может запросить нужные поля с той же аватаркой именем и прочей лабудой. Притом то как эти данные там оказались инкапсулировано внутри класса Пользователь. Например что-то он получает при создании, что-то типа аватарки подгружает по запросу, и кэширует и т.д. Если использовать процедурный подход, эти нюансы придется знать вызывающему объекту.
Т.е. ООП это общение черных ящиков между собой, у которых известны интерфейсы взаимодействия и скрыты внутренности.

Это так в кратце.
Ответ написан
@ilyaromashev
Всю жизнь на linux, а глаза покраснели от винды.
Мне тут один парень очень доходчиво объяснил:

кароч смотри

до ООП был Фортран, Паскаль и прочая мурня

на этом всем писали проекты, со временем проекты вырастали и появилось понимание, что если не объеденять функционал по каким-то критериям, то поддержка превращается в кромешный ад

можно объеденять код по пакетам\библиотекам, но это не сильно упростило ситуацию, потому что такое разделение не особо поясняло где искать нужную функциональность и привело к дублированию кода

тогда появились отцы ООП в лице Бертрана Мейера и др

они заявили, что можно объеденять функционал по неким объектам, которые отражают реальную структуру процессов которые пытались автоматизировать

такой себе https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D...

в начале (язык SmallTalk) не было понятия класса

потом с появлением с++ его завезли попытавшись подружить изначальнуюю ООП концепцию с математической теорией классов

вот и все

если вкратце
Ответ написан
mak_ufo
@mak_ufo
Выше правильно сказали, что никто не понимает, что такое ООП. Если вы копнёте чуть глубже, то узнаете, что автор термина "ООП" считает, что Java, C++ и C# неправильно реализовали идею ООП. Чего только стоит его известнейшая фраза: «Я придумал термин «объектно-ориентированный» и могу сказать, что я не имел в виду С++»

Можете посмотреть на язык Smalltalk и интереса ради сравнить его с C#.

Затем можете посмотреть блога Егора Бугаенко, и вы узрите ещё одну версию правильного понимания ООП. Если быть точнее, то:
1) get и set использовать нельзя
2) static-методы использовать нельзя
3) NULL быть не должно
Ибо всё это по версии Бугаенко противоречит идеям ооп.

Ну а на работе вы будете просто разгребать императивную лапшу, написанную с помощью классов.
Итог: никто не знает, что такое ООП
Ответ написан
@artemt
Foolstack developer
Есть отличный бесплатный курс "Проектирование на языке C#" (ulearn.me)
Ответ написан
@starosta6123
Дело в мышлении. Я тоже долго не мог уловить суть ООП, а теперь не могу отказаться :-)

Из ничего появился бит, и объединились они в байт, и разделился байт на команды и данные, и стали они выполняться, и так прошел первый день.
И стали команды выстраиваться в последовательности и стали они программами, так прошел второй день.
И много команд собралось, не осилить их, стали объединять в подпрограммы и библиотеки, так прошел третий день.
И обрели язык, стали общаться по-человечески на четвертый день.
И стали слова объединятся в функции, так прошел пятый день.
И стали функции дружить с данными и строить с ними классы, на шестой день.
И стали классы обращаться в объекты и наследоваться.
И наступило светлое будущее...

А теперь на примере:

Можно записать такой алгоритм:
Взять белый лист бумаги
Взять красный карандаш
Нарисовать карандашом круг

Если нужно что-то поменять, то придется переписать алгоритм, так как он содержит встроенные данные
Взять синий лист бумаги
Взять белый карандаш
Нарисовать карандашом квадрат

Формально, это новый алгоритм, но подумайте, когда мы с вами проделываем эти действия, мы не задумываемся о бумаге, карандаше и т.п. Нам неважно, так как карандаш "умеет" оставлять след на бумаге и этого достаточно чтобы мы могли нарисовать, а бумага "умеет" хранить изображение. Это их функции, предназначение.

А если чуть глубже копнуть, то
Взять объект класса БУМАГА
Взять объект класса КАРАНДАШ
Нарисовать объектом КАРАНДАШ на объекте БУМАГА объект класса ФИГУРА

И теперь в начале просто инициализируем нужные объекты и делам полезное дело.

Ведь логично, если вы научились рисовать одним карандашом, то так же можете рисовать любым другим!!!
Вы не подстраиваете ваш выработанный алгоритм действий под конкретный объект и это здорово. Это и есть абстракция! А если в руку взять шариковую ручку? Снова учиться, т.е. стоить новый алгоритм? Нет, конечно.

Нас давно не было бы, если поменяй нам ложку, мы не смогли бы есть....

А наследование вообще мощная вещь.

На задачу в каждом случае можно посмотреть под разными углами, и вы в праве выбрать наилучший путь решения.

Рекомендую почитать про паттерны программирования, вот где можно проследить мощь ООП.

И напоследок повторюсь, ООП или функциональное программирование и т.п. это всего лишь метод мышления и решения задач.

Еще маленький пример, вспомните как учили сложение, а потом умножение, формально любое умножение представимо суммой, но ведь это не эффективно при росте расчетов, вся математика это абстракция над более простыми вещами.

Не бойтесь, придет время и вы скажете: Это же элементарно, Ватсон :-)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы
R-telematica Start Москва
от 160 000 руб.
MAXIMUM EDUCATION Москва
от 100 000 до 120 000 руб.
Аскон Санкт-Петербург
от 130 000 до 180 000 руб.
12 дек. 2018, в 08:07
1000 руб./за проект
12 дек. 2018, в 05:58
1000 руб./за проект
11 дек. 2018, в 21:41
500 руб./за проект