та я уже петтинг проскочил как-то) если есть лекции, идеальный вариант

так ты опиши какой уровень тебе надо, ты все питон показываешь барышням?

так ты опиши какой уровень тебе надо, ты все питон показываешь барышням?

Уровень джуниора, в контексте питона - вряд ли

просто для стартового понимания

язык программирования?

ну и английский или онли рашен?

смотри какую-нить благословенную джаву (гг) язык если русский есть - великолепно. Если нет - английский тоже сойдёт

https://www.youtube.com/watch?v=-gGLSxmw3jo

тогда держи Немчинского

прекрасно, благодарю

стойкое убеждение что ооп это просто структура данных + таблица диспетчеризации сообщений это хорошо или плохо?

стойкое убеждение что ооп это просто структура данных + таблица диспетчеризации сообщений это хорошо или плохо?

это тебе хоть как-то помогает жить?)

это тебе хоть как-то помогает жить?)

нуууууу

стойкое убеждение - всегда плохо

не, не пишу ооп

просто мб я идею неверно понял

не, не пишу ооп

а что пишешь?

а что пишешь?

а ничего

откуда тогда стойкое убеждение?)

просто мб я идею неверно понял

тут стоит уточнить про какое мы ООП. 1. есть ООП распространенное в массах - это то что началось с языка Simmula и про то что у тебя есть объекты, представленные данными и поведением 2. есть ООП которое придумал Алан Кей и которое хрен его знает что такое. У него "объекты" это не инстансы классов а скорее модули, которые обмениваются сообщениями друг с другом, где структура рантайма децентрализована (нет main рутины), что-то оооочень похожее на actor model (последнее по сути были сформулировано под влиянием smalltalk72 вроде)

то что ты описал - это с точки зрения компилятора в целом корректно. структура данных и табличка диспетчеризации.

тебе как программисту это не особо погоду делает (если только ты не компилятор пишешь)

а вот введение таких штук как "данные и поведение инкапсулированные в одной штуке и штука эта объект" - это уже интереснее. Тут можно и про полиморфизм начать говорить и про information expert и как декомпозицию строить

но в целом этот чат и был создан что бы приблизиться к понимаю "что такое ООП". ХОтя @f3ath мог бы просто Алану написать письмо

этот чат был создан чтобы научить меня в декомпозицию и grasp/solid. А письму Кею кто угодно может написать

этот чат был создан чтобы научить меня в декомпозицию и grasp/solid. А письму Кею кто угодно может написать

научился?)

ещё бы ответить на вопрос: а кому он нужен, этот идеально выведенный ооп)

научился?)

ну для каких-то задач, пожалуй да

а вот введение таких штук как "данные и поведение инкапсулированные в одной штуке и штука эта объект" - это уже интереснее. Тут можно и про полиморфизм начать говорить и про information expert и как декомпозицию строить

погуглю непонятные термины из последнего предложения. а что делает погоду? способ организации этих самых табличек и структур?

ещё бы ответить на вопрос: а кому он нужен, этот идеально выведенный ооп)

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

погуглю непонятные термины из последнего предложения. а что делает погоду? способ организации этих самых табличек и структур?

делает погоду - возможность более естественным образом декомпозировать систему (все таки система состоит из элементов и элементы удобно воспринимать как объекты, но это не точно), ну и изоляция. Последнее в целом это продолжение идей Дейкстры о структурном программировании.

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

ну мол ты не можешь сломать всю систему если изменения изолированы в пределах одного модуля и у тебя минимальные связи между модулями)

декомпозиция это разбиение системы на изолированные сущности (классы)?

декомпозиция это разбиение системы на изолированные сущности (классы)?

модули (куски)

декомпозиция это разбиение системы на изолированные сущности (классы)?

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

классы, функции, сервисы, слои

и повторюсь - Алан кей говорит что "объект это не не совсем инстанс класса"

сча цитату приведу

последний вопрос профит ооп для "микромира" это полиморфизм, а для "макромира" это изолированность?

странные вопросы от человека, который ни на чём и ни что не пишет

странные вопросы от человека, который ни на чём и ни что не пишет

почему?

последний вопрос профит ооп для "микромира" это полиморфизм, а для "макромира" это изолированность?

ООП и полиморфизм это разные идеи и они живут вполне независимо друг от друга

последний вопрос профит ооп для "микромира" это полиморфизм, а для "макромира" это изолированность?

не столько полиморфизм, сколько IoC, который этот полиморфизм позволяет, как я понимаю

т.е. полиморфизм как средстводостижения IoC

почему?

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

т.е. полиморфизм как средстводостижения IoC

но это можно и без ООП делать)

читаю вас и слышу, как хрустят шаблоны...

читаю вас и слышу, как хрустят шаблоны...

да ладно) в 99% случаев всё равно будет "хуяк-хуяк и в продакшен"

> The basic misunderstanding here is between what I meant as objects and what the term has been turned into. The main one was that the intent was to have the interior of objects be a system of objects. I.e. "objects" and "modules" are the same thing. This harmonizes with the compositional ideas above. Another misunderstanding was the idea of objects as "data types" or as "operators" (both of which can be done by virtue of an object being semantically a whole computer). But we really thought about objects as "loci of goal satisfactions" and that the best messages would be to request goals and the best objects would be those who can satisfy "large goals". The universality of objects could be used to make every part, with the aim to get stronger semantically as more comprehensive objects were made. Some of the precursor ideas here were "systems theory" (Bertalanfy, Alexander, etc.), programming as "constraint solving" (Sketchpad), etc. In practice, we did a lot less during the Parc period because of some of the resource constraints of the 70s. Still, it was clear that composition was almost always better than inheritances, and that recursive systems of name spaces was better than the more "Lisp-like" architecture we used for references, etc.

либо другая крайность - две недели париться над тем, как сделать "правильно", а потом отгребать за проваленные сроки

но это можно и без ООП делать)

можно, я ж не спорю. это я у дяди Боба подслушал, что основная ценность полиморфизма (в обывательском понимании ООП) заключается в IoC

я вообще о классической универской формулировке про три кита ООП

можно, я ж не спорю. это я у дяди Боба подслушал, что основная ценность полиморфизма (в обывательском понимании ООП) заключается в IoC

в IoC или DIP?)

я вообще о классической универской формулировке про три кита ООП

everything is object, late binding и message passing?

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

everything is object, late binding и message passing?

если у тебя такое было в универе - хороший у тебя универ инкапсуляция, наследование, полиморфизм

либо другая крайность - две недели париться над тем, как сделать "правильно", а потом отгребать за проваленные сроки

правильный ооп - это умение соблюсти баланс между книжными академическими вариантами и суровым кнутом продакт оунеров)

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

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

правильный ооп - это умение соблюсти баланс между книжными академическими вариантами и суровым кнутом продакт оунеров)

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

если у тебя такое было в универе - хороший у тебя универ инкапсуляция, наследование, полиморфизм

нет конечно)) но как бы тебе так сказать.... в моем универе если ты хочешь чего-то узнать - тебе не на лекции надо идти а с проподом пива попить)

в IoC или DIP?)

да, DI

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

вот я читал книжки там говорят "можно так, а можно так, а еще можно так" а потом ты сидишь и думаешь "а я сделаю так, вот так и еще с подвывертом вот здесь" потому, что так лучше - ведь в книжке написано всегда обращаешь внимание на утверждения в первую очередь, а не на поправки к ним

ну вопрос в кол-ве книжек) маст хэв набор за спиной есть. А всякую наркомань, которая выписывает идеальный мир - не доводилось :)

ну вопрос в кол-ве книжек) маст хэв набор за спиной есть. А всякую наркомань, которая выписывает идеальный мир - не доводилось :)

ну так если не доводилось - может их и нет?)

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

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

ну так если не доводилось - может их и нет?)

может и нет) но часть местных обсуждений тактично намекает, что всё таки где-то что-то зарыто)

нет конечно)) но как бы тебе так сказать.... в моем универе если ты хочешь чего-то узнать - тебе не на лекции надо идти а с проподом пива попить)

в моем универе не с кем пиво пить было были, конечно, несколько нормальных преподов, но склонных к усложнению всего и вся - слишком много пива с такими пить придется, чтобы что-то понять)

может и нет) но часть местных обсуждений тактично намекает, что всё таки где-то что-то зарыто)

это рекурсивный намек)

это рекурсивный намек)

да тут частенько Сергей чё-нить задвинет и ощущаешь себя полным кретином) явно где-то что-то ещё не дочитал)

радоваться надо наоборот - есть, что еще дочитать, и для определения этого не нужно лезть в дебри)

радуемся потихоньку)

и продолжаем говнокодить)

ну ведь уже понимаем, что говнокодим - так и до рефакторинга недалеко

рефакторинг - процесс перманентный)

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

1. всегда стоит разделять статический мир (компайл тайм, исходники, код) и рантайм. Можно на тему семантического разрыва почитать. И смысл в том что бы снизить различия того как код читается и как он выполняется. 2. по поводу иерархии типов - это вопрос абстракции данных. Это тема не привязана к ООП опять же и больше про предсказуемость и поведение, про контракты. Это в целом работает на любом уровне, то есть нет разделения на микро и макро. Просто на каком-то уровне ты можешь забить, ибо "достаточно маленькая штука, а что внутри никого не парит". 3. зависимости.... вот тут то о чем @f3ath говорит - инверсия зависимостей, когда у тебя направление зависимостей в коде отличается от реальных зависимостей в рантайме. Или late binding. Вот эта штука позволяет очень интересные вещи. 4. в любом случае весь вопрос в том что бы проще было вносить изменения. Изменения проще вносить когда эффект изменений не распространяется далеко. А это можно сделать только уменьшая количество зависимостей и контролируя их, а так же изолируя работу с данными. Просто представь себе систему как сеть маленький компьютеров, каждый из которых хранит какие-то данные (и доступа к ним напрямую нет), и которые что-то с этими данными делают. Ты можешь по сети отправлять сообщения мол "надо что-то пересчитать" и нужный компьютер тебе это сделает. Если тебе надо "заменить" компьтер с бухгалтерским учетом - ты просто выкидываешь старый и заменяешь на новый. Системе в целом пофигу, до тех пор пока не меняется поведение этого комьютера (протокол если хочешь) с точки зрения других.

ну ведь уже понимаем, что говнокодим - так и до рефакторинга недалеко

ты про "переписать все к херам" или про рефакторинг?

давай разделять эти понятия

ты про "переписать все к херам" или про рефакторинг?

про первое, конечно же)

ты про "переписать все к херам" или про рефакторинг?

я, конечно, дурной, но понимаю, что переписать все нахрен - это нереалистично поэтому применяю подход "переписать все нахрен маленькими кусочками, не удаляя старое в процессе"

1. всегда стоит разделять статический мир (компайл тайм, исходники, код) и рантайм. Можно на тему семантического разрыва почитать. И смысл в том что бы снизить различия того как код читается и как он выполняется. 2. по поводу иерархии типов - это вопрос абстракции данных. Это тема не привязана к ООП опять же и больше про предсказуемость и поведение, про контракты. Это в целом работает на любом уровне, то есть нет разделения на микро и макро. Просто на каком-то уровне ты можешь забить, ибо "достаточно маленькая штука, а что внутри никого не парит". 3. зависимости.... вот тут то о чем @f3ath говорит - инверсия зависимостей, когда у тебя направление зависимостей в коде отличается от реальных зависимостей в рантайме. Или late binding. Вот эта штука позволяет очень интересные вещи. 4. в любом случае весь вопрос в том что бы проще было вносить изменения. Изменения проще вносить когда эффект изменений не распространяется далеко. А это можно сделать только уменьшая количество зависимостей и контролируя их, а так же изолируя работу с данными. Просто представь себе систему как сеть маленький компьютеров, каждый из которых хранит какие-то данные (и доступа к ним напрямую нет), и которые что-то с этими данными делают. Ты можешь по сети отправлять сообщения мол "надо что-то пересчитать" и нужный компьютер тебе это сделает. Если тебе надо "заменить" компьтер с бухгалтерским учетом - ты просто выкидываешь старый и заменяешь на новый. Системе в целом пофигу, до тех пор пока не меняется поведение этого комьютера (протокол если хочешь) с точки зрения других.

о, спасибо за ответ

и всему чати тоже

полезный чат получился, ага

тут много раз уже проскакивала идея запиннить список макулатуры

тут много раз уже проскакивала идея запиннить список макулатуры

так ведь уже

тут много раз уже проскакивала идея запиннить список макулатуры

https://oopru.github.io/

гит для кого сделан?)

я много раз спрашивал, теперь запомнил)

оу... а как я профакапил его, спасибо

структурировать бы его получше, но на это надо время

дык открывайте пулреквесты

да тут частенько Сергей чё-нить задвинет и ощущаешь себя полным кретином) явно где-то что-то ещё не дочитал)

я регулярно ловлю себя на мысли что есть люди, для которых все это ООП настолько очевидно, что просто сидишь и думаешь... что ж такое они знают чего не знаю я.... почему у них все так легко и просто... как отличается их ооп от моего? почему? Это потому что 20 лет назад они застали какие-то системы которые как-то отличались?

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

я регулярно ловлю себя на мысли что есть люди, для которых все это ООП настолько очевидно, что просто сидишь и думаешь... что ж такое они знают чего не знаю я.... почему у них все так легко и просто... как отличается их ооп от моего? почему? Это потому что 20 лет назад они застали какие-то системы которые как-то отличались?

ну у меня степень фанатизма чуток поменьше, но +/- так и бывает. Ток не про ооп, а в целом про всё.

одних только c2 и фаулера хватит чтоб на пару месяцев упороться чтением

Давайте устроим флешмоб, завтра каждый по пулреквесту(А коняш разгребать всё будет))

вот на днях посмотрел докладик Уди (любимый персонаж @zloyuser ) - и как-то все вроде то же что и раньше но совсем по другому и от тогоа немного теперь сложнее...

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

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

одних только c2 и фаулера хватит чтоб на пару месяцев упороться чтением

эт да

ну у меня степень фанатизма чуток поменьше, но +/- так и бывает. Ток не про ооп, а в целом про всё.

особенно когда чатики читаешь)