Войти
ФлеймФорумОбщее

Как обьяснить людям, зачем нужны классы, наследование и ООП?

Страницы: 1 2 3 4 5 6 7 Следующая »
#0
14:08, 19 сен. 2018

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

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

Управление зависимостями

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

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

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

Все известные ООП-шные принципы, включая Принцип Единой Ответственности, понятия связности и связанности (cohesion и coupling) и многие другие, призваны бороться с неотъемлемой сложностью (essential complexity) нашей бизнес-области и сводить случайную сложность (accidental complexity) к минимуму. Все наши продуманные абстракции, хитроумные паттерны и высокоуровневые языки программирования призваны акцентировать внимание на естественной сложности задачи, скрывая на «уровень ниже» несущественные подробности без которых можно обойтись.

Исходник: http://sergeyteplyakov.blogspot.com/2012/11/blog-post.html

Вопрос: что здесь можно не понять?
Ну т.е. предположим есть новичок, который не шарит, и задаёт контр-вопрос. Или контр-пример в котором он может "сделать тоже самое, но своим способом".
Вот, какие мысли от лица такого новичка тут можно сгенерировать?


#1
14:19, 19 сен. 2018

f1ufx_
> настолько подробно, что я просто не понимаю, что тут пожно не понять

Именно в этом и проблема - из ООП выдумали мешанину разрозненных идей и принципов, слепили из них убер-колобок и разжёвывают его на протяжении сотен страниц могучих книг.
В то время как это всего лишь техника динамической диспетчеризации, которая объясняется не дольше, чем объясняется процедурное программирование (откуда оно выросло): https://gamedev.ru/flame/forum/?id=234027
Выходит, что те кто его так долго объясняют и наделяют миллионом малозначимых свойств просто сами чётко не понимают что и зачем было придумано.

#2
14:25, 19 сен. 2018
сами чётко не понимают что и зачем было придумано.

Именно поэтому мне интересно найти формулировки, которые бы позволили мне обьяснять это другим людям.
#3
14:33, 19 сен. 2018

f1ufx_
Курить 11-13 главы второго (!) издания Страуструпа (про ОО-проектирование), последние главы "Мифического Человеко-месяца" (там приведены мнения классиков про правильное использование ООП, мол, почти серебряная пуля) и 7-й том японского 11-томника по микроэлектронике, тот, что про SmallTalk (там ООП выводится из семантики).
Противопоказаны: Дейкстра, Броуди и Элджер.

#4
14:39, 19 сен. 2018

gudleifr
Ок, на твой ответ я выдают контр-пример:
"а чё, своими словами обьяснить не можешь? ну значит ты сам не понимаешь! и прочтение этих глав ничего тебе не дали. значит и мне не дадут, а значит бессмысленно их читать".

#5
14:40, 19 сен. 2018

ООП - набор эвристик, в первую очередь нужно объяснять полезность каждой эвристики в отдельности.

>На что мне резонно отвечают: вероятность ошибки зависит от умности программиста. сколько не было бы сущностей - плохой программист понаделает ошибок, а хороший - в любом коде не будет делать ошибок.
Это не резенно :-D

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

#6
14:44, 19 сен. 2018

Tiendil
Это то фигня, типичный пример. Я встречался и ещё с более крутым ответом. Мне как то сказали так:
"В любой программе есть ошибки. Зачем делать код более понятным и снижать вероятность ошибиться, когда один хрен в любой программе есть ошибки, и один хрен за 2 недели перед сдачей проекта будет аврал?".
Ну это конечно клинический случай, один на тысячу, думаю не стоит такое уже рассматривать. Но вот идея о том, что умный программист разберёться в любом коде, а глупый - понаделает ошибок, какие бы паттерны не применять - с этим изречением я встречаюсь очень часто.

#7
14:46, 19 сен. 2018

f1ufx_
> При попытке обьяснить зачем нужны классы, я говорю о человеческом факторе.
Не нужно говорить, просто посади писать движок!
Через несколько попыток все само встане на свои места)

#8
14:47, 19 сен. 2018

f1ufx_
> а чё, своими словами обьяснить не можешь?
Могу. Но, во-первых, читать умные книжки полезно.
Во-вторых, зачем повторять то, что люди, обладающие признанным литературным талантом, старались-писали именно для такого случая?
В-третьих, я уже очень далеко отошел от ООП, и воспринимаю его, как детскую болезнь. См. мои заметки.

f1ufx_
> мне не дадут, а значит бессмысленно их читать".
Да, Вам не дадут.

#9
14:48, 19 сен. 2018
В первую очередь человеку надо объяснить, что лажают все. Если это нельзя объяснить на примере самого человека, значит у него опыта вообще нет.

И всё таки, как сказал Филип Дик: "когда тебя спрашивают - надо отвечать".
И мне кажется, что ответ, данный в топик старте выдержкой из статьи - весьма полный. Если у человека хватит сил чтобы сконцентрироваться и выслушать такой ответ..
#10
14:49, 19 сен. 2018

emptiness_rain

Не нужно говорить, просто посади писать движок!
Через несколько попыток все само встане на свои места)

Тут на соседнем форуме есть девушка, которая уже больше двух лет пишет движок, и у неё до сих пор на свои места ничего не встало.
#11
14:53, 19 сен. 2018

emptiness_rain
> Не нужно говорить, просто посади писать движок!
И сам садись, 2.

Кармак без этой фигни написал, а вы как ни садитесь - хоть с ООП, хоть классами - умнее не станете.

#12
14:53, 19 сен. 2018

gudleifr
Ты нашёл отмазки, которыми, вероятно, сохранил уважение к тебе у вопрошающего. Человек остался думать, что ты умный. Вертно, это уже не плохо. Но цели ты не достиг. Целью было обьяснить человеку (ответить на его вопрос) связанный с необходимостью применения ООП и/или паттернов. Да, вероятно отправить читать книги - это тоже вариант. Но тогда встаёт второй вопрос: как мотивировать человека читать книги, как убедить его в том, что только из книг он получит ответ? Ведь если его не мотивировать/не убедить, он пойдёт и дальше изобретать велосипеды в своём коде, коммитить их в твой проект со словами: "так почему так нельзя?! обьясните!". И мы возвращаемся к тому, с чего начали...

#13
14:56, 19 сен. 2018

f1ufx_
> Да, вероятно отправить читать книги - это тоже вариант.
Я не его отправлял, а Вас. Вы хотите вооружиться тезисами "за ООП"? Я их Вам преподнес на тарелочке.

#14
14:56, 19 сен. 2018

WhiteWolf
Стать имнее тут никто не собирался. Тема о другом.

Страницы: 1 2 3 4 5 6 7 Следующая »
ФлеймФорумОбщее

Тема в архиве.