Именно это под словом "пивот" и подразумевают, проект меняется иногда даже больше, чем на половину, и по сути да — это уже новый проект, но часть кодовой базы можно переиспользовать.
Чем приложение меньше, тем меньше смысла грузить немаленький jQuery
Насколько я понимаю, они со временем выпиливают слой совместимости с совсем уж древними браузерами, и как следствие размер библиотеки уменьшается со временем. Ради интереса посмотрел, текущая версия (3.4.1) занимает 86 kb и это ещё без gzip. По текущим реалиям будет точнее называть его "пренебрежимо маленький jQuery".
Насчёт красоты wxWidgets можно ещё добавить, что он подстраивается под нативный look-n-feel, поэтому скриншот одной и той же формы будет выглядеть по-разному в разных OS и DE. Например, на MacOS X такой вид:
Так что для кросс-платформенного GUI wxWidgets — практически идеальный вариант.
Ответ, вообще-то, очевиден — только не таков, каким он вам кажется.
Если вы намекаете, что ответ — "исторически сложилось", то это неправильный ответ.
Авторы Inkscape, вообще-то, начинали с исходников Sodipodi, созданном на языке C без использования ООП.
Ох, как же вы живёте то теперь со знанием, что векторный редактор можно и без ООП написать xD
Кстати, в C вполне возможно использовать ООП (не забывайте, что это парадигма, и что наличие классов — не является её требованием)
Разумеется когда вы добавляете ООП в уже существующий код — ваши руки оказываются «связанными».
Что значит "разумеется"? Inkscape уж 15+ лет существует… пару раз что угодно переписать можно было, если бы была насущная необходимость.
Да и вообще когда есть понимание, как надо переделать и зачем, руки ничто не связывает.
А речь шла не про определение, а про утверждение, что ООП придумали не для простых задач.
Если про это не написали в русской Википедии на странице про ООП, то для вас это неочевидно?
Я бы даже сказал, что не слишком громким обобщением, будет сказать, что в программировании уже лет 70 как ничего не придумывают для простых задач. Основной драйвер развития парадигм и инструментария — борьба со сложностью.
И именно на этой борьбе построили удачные маркетинговые компании, которые реализовали небольшое подмножество идей ООП, типа того же C++. Да с него плевались те, кто придумал ООП, писали "что за хрень?", но маркетинг сделал своё дело. Но это 35 лет назад можно было на что угодно навесить ярлык ООП, лишь бы продать. Сейчас любой желающий может ознакомиться с оригинальным описанием парадигмы, осознать масштабы концептуальных искажений в мейнстрим языках и сделать выводы. И практически применимые выводы, потому что ООП — это не технология, а парадигма — совокупность идей и понятий, определяющих стиль написания программ. Как только поймёте парадигму, сможете начать её применять в любом языке.
Конечно не каждый студент будет делать в своей работе векторный графический редактор… Ну так то же самое можно про что угодно сказать.
Как сказать… Есть классы задач, которые решаются постоянно, ежедневно в тысячах компаний по всему свету, просто потому что универсального решения нет или пока не нашли, но есть универсальные принципы и подходы к их решению. И именно их было бы гораздо полезнее рассматривать в учебных целях. Нечто подобное рассматривают в книгах про паттерны проектирования.
Вот только это сложный и путанный путь: сначала объяснить ООП так, чтобы никто не понял зачем оно, а когда задолбается, начал паттерны изучать или переизобретать.
Обратите внимание, почти все паттерны выделяют объекты по поведению (поведение + данные, необходимые для его реализации), а почти все учебники и статьи для начинающих продолжают нести дичь про объекты реального мира и про то, что объект — это модель, это данные и всевозможные действия над этими данными (= фундаментальная ошибка понимания ООП).
P.S. Вы всерьёз думаете, что формат комментариев подходит для обсуждения создания векторного редактора с нуля? Мало того, что это практически бессмысленная задача (у вас бюджета не хватит подвинуть конкурентов), так она ещё и огромна.
Но раз уж вам захотелось дзена, то почитайте исходники того же Inkscape и ответьте на вопросы: Почему класс Circle не наследует от класса Shape? И не содержит метода draw? Авторы Inkscape не дураки, чтобы делать так, как описано в "учебниках" по ООП.
Рекурсивность появится если паттерн будет состоять из самого себя, а не просто из набора других паттернов.
Если бы было так:
var person = new Person
{
Name = new FullName
{
First = "Vasya",
Last = "Pupkin",
X = "secret",
},
Age = 42,
};
if (person is { X: var x})
{
Console.WriteLine(x);
}
то можно было бы сказать, что есть рекурсивный паттерн, который соответственно запускает рекурсивный поиск совпадения на любую глубину вложенности.
Если изучаете конкретный граф, то его ввести в комп сначала надо.
Так ввести (в виде данных), или вывести на монитор в виде картинки? Вы уж определитесь там..
И, опять, кто Вам сказал, что ООП придумали не для простых задач?
Это просто факт. Читайте первоисточники.
Что значит «просто другая»? Там что: другие компы, другие ОС, другие ЯП?
То и значит. Разные условия, разные цели, разные типы задач, разные процессы разработки. Да и языки другие, для научной разработки лучше всего подходят Haskell, Idris, Matlab, Fortran, etc. Julia вон недавно завезли, не пробовали ещё?
А ООП вам там в подавляющем большинстве задач нафиг не сдалось, если честно. Научная разработка — вотчина ФП (чистая математика, самый сок) и ПП (там где скорость критична, а алгоритмов с неизменяемыми данными не хватает).
Да, и эти люди обычно решают наиболее сложные задачи.
Это смотря по каким критериям измерять сложность. Вы лишь сравниваете что зеленее? тёплое или мягкое?
Посади тех же людей, которые решают сложные научные задачи, писать промышленный проект средней руки, и они облажаются по полной. Так же как и в обратную сторону.
В пром. разработках очень много тривиальных задач.
Можно подумать в научных мало… Все расчёты сводятся в конечном итоге к большому кол-ву тривиальных задач.
Это неважно. Важно, что нетривиальных задач тоже много.
Имхо, не стоит ничего объяснять на искусственных примерах. И да, это общий вопрос для любых концепций. Всегда можно найти достаточно простой пример, но при этом адекватный и практически применимый.
Проблема в примерах с фигурами и животными, в том, что они сами по себе являются примерами непонимания как и зачем применять ООП, примерами того, как делать не надо. При этом люди на них осваивают это самое ООП. А потом, когда они набираются опыта, пишут статьи типа "Чем быстрее вы забудете ООП, тем лучше для вас". А всё потому, что изначально учились на дрянных и совершенно неадекватных примерах.
Примеры разбора их неадекватности: 1, 2
ООП — полезная парадигма, но только если понимать зачем она была создана и для чего. А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.
Но название фичи ведь должно кратко описывать её суть, а не просто из случайных слов состоять? А тут в чём рекурсивность? Тут скорее "Nested deconstruction"
Зависит от степени вашего формализма )))
Можно понимать первый пункт так:
Программа состоит из объектов, нет никакого кода, исполняющегося вне объектов.
При этом что там внутри объектов происходит (п.3) и как они коммуницируют (п.2) — темы отдельные и формально не требуют ни наличия объектов внутри own memory объекта, ни использования объектов для передачи сообщений.
Будет Вам известно, что те самые кружочки могут обозначать вершины молекулярных графов или атомы. А изучение таких графов позволяет..
Вы в упор не читаете, что вам пишут. Речь была про примеры, на которых зачастую объясняют ООП в учебниках. Вы сначала убеждали, что они прекрасны, и ничего сложнее для понимания ООП не надо. А теперь обижаетесь на простые логические выводы из ваших же слов. Я же вам пытаюсь объяснить, что ООП придумали не для простых задач, а для того чтобы упростить решение сложных. Поэтому именно сложные задачи необходимо рассматривать и в учебниках, иначе у людей формируется искажённое понимание ООП.
Что касается графов, их изучение и отрисовка — это 2 несвязанные задачи.
первым делом нужно отметить Вашу убежденность в превосходстве промышленной разработки над научной
Вообще ничего подобного. Научная разработка она просто другая. Зачем сравнивать тёплое с мягким. Единственный факт, на который стоило бы обратить внимание, что в научной разработке занято на порядок, а то и на пару порядков, меньше людей. Поэтому при обсуждении примеров для массовых учебников и статей, разумнее опираться на промышленную обработку. Это не вопрос какого-то мнимого превосходства, это просто вопрос здравого смысла.
Так и осталось непонятным зачем этот ряд
Вы английский знаете? У каждого из этих объектов одна ответственность, которая выражена в его названии.
Можно было бы тоже статью накатать с подробной расшифровкой, но я не вижу в этом смысла. Кто сталкивался с подобным классом задач, тот и так поймёт что я написал. А кто не сталкивался — ну может им и не надо. Собственно, может им и ООП не надо.
Про унарный оператор ~v0s меня уже опередил. С этим как раз ничего менять не пришлось бы. Технически бинарный оператор ^ добавить то можно, но вряд ли одному символу станут придавать настолько разный смысл в зависимости от кол-ва операндов.
А x?. по мне всё равно дико смотрится, особенно для тех, у кого есть опыт работы с Ruby, где существует совершенно логичная конвенция, что x? всегда возвращает boolean, ну типа active? вместо isActive. Думаю, всё равно в итоге нормальную Maybe монаду завезут и эти? после x станут deprecated.
Хз, зависит от условий конкретной стажировки. Может и можете. Я просто к тому, что если у человека 0 лет опыта работы, то лучше написать что и как долго он изучал, чем ничего не написать.
Ну так в резюме и пишут опыт работы в годах. Но тут то речь о стажировке и первом потенциальном месте работы, так что можно писать, что угодно (просто для информации).
Да фичи то ещё ладно, а вот синтаксис для них они выбирают какой-то слишком странный.
В MiddleName?[0] знак вопроса ни к селу, ни к городу, семантики никакой. Сделали бы просто, что для переменной Nullable-типа вызов любого метода возвращает null обёрнутый в Nullable-тип возврата, если в самой переменной был null. ^0 как автор в статье написал, лучше бы для возведения в степень использовали.
А тут можно было бы ~0
термин recursive patterns — это еще на порядок хуже
Зачем для этого вообще отдельный термин? Это же самый обычный паттерн-матчинг с нормальной деконструкцией и биндингом сматченных значений в переменные.
Можно было бы обозвать "Pattern matching restrictions have been eased."
Мой (ведущий) НИИ РАН десятилетиями не занимается промышленной разработкой, и многие другие институты и универы во всем мире не занимаются.
Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.
Так имеет Smalltalk отношение к сути вопроса или не имеет?
Есть абстрактная идея ООП, а есть её реализации. Поскольку вы хотите не только теорию, но и конкретику, то вам придётся ознакомиться и с реализациями ООП:
Smalltalk — классическая class-based реализация ООП
Erlang/OTP — actor-based реализация ООП
При этом то, что справедливо для конкретной реализации, не всегда справедливо для парадигмы как таковой.
Какое мне дело, что у меня с какой-то точки зрения «не правильное» ООП.
Да в принципе никакое, пока вы сами по себе что-то там пишете, можете хоть своим личным ООП руководствоваться. Но раз взялись писать статью, то потрудитесь хоть немного разобраться в теме, прежде чем писать о ней. И нет, прочитать одну статью на википедии недостаточно.
У Вас
sendMsgAsync(eventLogger, event)
Где у меня eventLogger?
Более того Вы ж сказали, что возьмете не мой, а свой пример
OMFG, вы читать вообще умеете, я же русским языком написал, что взял синтаксис из вашего примера, чтобы вам понятнее было. Напоминаю: sendMsg ({куда}, {сообщение});
И «прокинуть эвент для обработки ряду объектов» это не
Разумеется конкретному,
Каждая строка отправляет сообщение конкретному объекту, а все вместе они образуют ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)
Из этого «ответа» я делаю вывод, что Вы не видите ничего страшного в том, что триллионы объектов с миллионов компов всей Земли будут атаковать друг друга сообщениями через инет.
О чём вы вообще говорите? Какие миллионы компов всей Земли? Хоть это и происходит, но это вообще не в тему обсуждения. Вы вообще понимаете, что такое горизонтальное масштабирование системы? Или кроме desktop-приложений на Delphi ничего не делали?
Именно это под словом "пивот" и подразумевают, проект меняется иногда даже больше, чем на половину, и по сути да — это уже новый проект, но часть кодовой базы можно переиспользовать.
Насколько я понимаю, они со временем выпиливают слой совместимости с совсем уж древними браузерами, и как следствие размер библиотеки уменьшается со временем. Ради интереса посмотрел, текущая версия (3.4.1) занимает 86 kb и это ещё без gzip. По текущим реалиям будет точнее называть его "пренебрежимо маленький jQuery".
Вынос в константы однозначно нужен. А вот вынос в конфиг может оказаться и оверинженерингом. Про YAGNI тоже не нужно забывать.
Насчёт красоты wxWidgets можно ещё добавить, что он подстраивается под нативный look-n-feel, поэтому скриншот одной и той же формы будет выглядеть по-разному в разных OS и DE. Например, на MacOS X такой вид:
Так что для кросс-платформенного GUI wxWidgets — практически идеальный вариант.
Если вы намекаете, что ответ — "исторически сложилось", то это неправильный ответ.
Ох, как же вы живёте то теперь со знанием, что векторный редактор можно и без ООП написать xD
Кстати, в C вполне возможно использовать ООП (не забывайте, что это парадигма, и что наличие классов — не является её требованием)
Что значит "разумеется"? Inkscape уж 15+ лет существует… пару раз что угодно переписать можно было, если бы была насущная необходимость.
Да и вообще когда есть понимание, как надо переделать и зачем, руки ничто не связывает.
Если про это не написали в русской Википедии на странице про ООП, то для вас это неочевидно?
Я бы даже сказал, что не слишком громким обобщением, будет сказать, что в программировании уже лет 70 как ничего не придумывают для простых задач. Основной драйвер развития парадигм и инструментария — борьба со сложностью.
И именно на этой борьбе построили удачные маркетинговые компании, которые реализовали небольшое подмножество идей ООП, типа того же C++. Да с него плевались те, кто придумал ООП, писали "что за хрень?", но маркетинг сделал своё дело. Но это 35 лет назад можно было на что угодно навесить ярлык ООП, лишь бы продать. Сейчас любой желающий может ознакомиться с оригинальным описанием парадигмы, осознать масштабы концептуальных искажений в мейнстрим языках и сделать выводы. И практически применимые выводы, потому что ООП — это не технология, а парадигма — совокупность идей и понятий, определяющих стиль написания программ. Как только поймёте парадигму, сможете начать её применять в любом языке.
Как сказать… Есть классы задач, которые решаются постоянно, ежедневно в тысячах компаний по всему свету, просто потому что универсального решения нет или пока не нашли, но есть универсальные принципы и подходы к их решению. И именно их было бы гораздо полезнее рассматривать в учебных целях. Нечто подобное рассматривают в книгах про паттерны проектирования.
Вот только это сложный и путанный путь: сначала объяснить ООП так, чтобы никто не понял зачем оно, а когда задолбается, начал паттерны изучать или переизобретать.
Обратите внимание, почти все паттерны выделяют объекты по поведению (поведение + данные, необходимые для его реализации), а почти все учебники и статьи для начинающих продолжают нести дичь про объекты реального мира и про то, что объект — это модель, это данные и всевозможные действия над этими данными (= фундаментальная ошибка понимания ООП).
P.S. Вы всерьёз думаете, что формат комментариев подходит для обсуждения создания векторного редактора с нуля? Мало того, что это практически бессмысленная задача (у вас бюджета не хватит подвинуть конкурентов), так она ещё и огромна.
Но раз уж вам захотелось дзена, то почитайте исходники того же Inkscape и ответьте на вопросы: Почему класс Circle не наследует от класса Shape? И не содержит метода draw? Авторы Inkscape не дураки, чтобы делать так, как описано в "учебниках" по ООП.
Вот с этим не поспоришь :)
Жаль только в заголовке оно упоминается )))
Рекурсивность появится если паттерн будет состоять из самого себя, а не просто из набора других паттернов.
Если бы было так:
то можно было бы сказать, что есть рекурсивный паттерн, который соответственно запускает рекурсивный поиск совпадения на любую глубину вложенности.
Так ввести (в виде данных), или вывести на монитор в виде картинки? Вы уж определитесь там..
Это просто факт. Читайте первоисточники.
То и значит. Разные условия, разные цели, разные типы задач, разные процессы разработки. Да и языки другие, для научной разработки лучше всего подходят Haskell, Idris, Matlab, Fortran, etc. Julia вон недавно завезли, не пробовали ещё?
А ООП вам там в подавляющем большинстве задач нафиг не сдалось, если честно. Научная разработка — вотчина ФП (чистая математика, самый сок) и ПП (там где скорость критична, а алгоритмов с неизменяемыми данными не хватает).
Это смотря по каким критериям измерять сложность. Вы лишь сравниваете что зеленее? тёплое или мягкое?
Посади тех же людей, которые решают сложные научные задачи, писать промышленный проект средней руки, и они облажаются по полной. Так же как и в обратную сторону.
Можно подумать в научных мало… Все расчёты сводятся в конечном итоге к большому кол-ву тривиальных задач.
Это неважно. Важно, что нетривиальных задач тоже много.
Имхо, не стоит ничего объяснять на искусственных примерах. И да, это общий вопрос для любых концепций. Всегда можно найти достаточно простой пример, но при этом адекватный и практически применимый.
Проблема в примерах с фигурами и животными, в том, что они сами по себе являются примерами непонимания как и зачем применять ООП, примерами того, как делать не надо. При этом люди на них осваивают это самое ООП. А потом, когда они набираются опыта, пишут статьи типа "Чем быстрее вы забудете ООП, тем лучше для вас". А всё потому, что изначально учились на дрянных и совершенно неадекватных примерах.
Примеры разбора их неадекватности: 1, 2
ООП — полезная парадигма, но только если понимать зачем она была создана и для чего. А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.
Но название фичи ведь должно кратко описывать её суть, а не просто из случайных слов состоять? А тут в чём рекурсивность? Тут скорее "Nested deconstruction"
Зависит от степени вашего формализма )))
Можно понимать первый пункт так:
Программа состоит из объектов, нет никакого кода, исполняющегося вне объектов.
При этом что там внутри объектов происходит (п.3) и как они коммуницируют (п.2) — темы отдельные и формально не требуют ни наличия объектов внутри own memory объекта, ни использования объектов для передачи сообщений.
Вы в упор не читаете, что вам пишут. Речь была про примеры, на которых зачастую объясняют ООП в учебниках. Вы сначала убеждали, что они прекрасны, и ничего сложнее для понимания ООП не надо. А теперь обижаетесь на простые логические выводы из ваших же слов. Я же вам пытаюсь объяснить, что ООП придумали не для простых задач, а для того чтобы упростить решение сложных. Поэтому именно сложные задачи необходимо рассматривать и в учебниках, иначе у людей формируется искажённое понимание ООП.
Что касается графов, их изучение и отрисовка — это 2 несвязанные задачи.
Вообще ничего подобного. Научная разработка она просто другая. Зачем сравнивать тёплое с мягким. Единственный факт, на который стоило бы обратить внимание, что в научной разработке занято на порядок, а то и на пару порядков, меньше людей. Поэтому при обсуждении примеров для массовых учебников и статей, разумнее опираться на промышленную обработку. Это не вопрос какого-то мнимого превосходства, это просто вопрос здравого смысла.
Вы английский знаете? У каждого из этих объектов одна ответственность, которая выражена в его названии.
Можно было бы тоже статью накатать с подробной расшифровкой, но я не вижу в этом смысла. Кто сталкивался с подобным классом задач, тот и так поймёт что я написал. А кто не сталкивался — ну может им и не надо. Собственно, может им и ООП не надо.
Про унарный оператор
~v0s меня уже опередил. С этим как раз ничего менять не пришлось бы. Технически бинарный оператор^добавить то можно, но вряд ли одному символу станут придавать настолько разный смысл в зависимости от кол-ва операндов.А
x?.по мне всё равно дико смотрится, особенно для тех, у кого есть опыт работы с Ruby, где существует совершенно логичная конвенция, чтоx?всегда возвращает boolean, ну типаactive?вместоisActive. Думаю, всё равно в итоге нормальную Maybe монаду завезут и эти? после x станут deprecated.Хз, зависит от условий конкретной стажировки. Может и можете. Я просто к тому, что если у человека 0 лет опыта работы, то лучше написать что и как долго он изучал, чем ничего не написать.
Ну так в резюме и пишут опыт работы в годах. Но тут то речь о стажировке и первом потенциальном месте работы, так что можно писать, что угодно (просто для информации).
Да фичи то ещё ладно, а вот синтаксис для них они выбирают какой-то слишком странный.
В
MiddleName?[0]знак вопроса ни к селу, ни к городу, семантики никакой. Сделали бы просто, что для переменной Nullable-типа вызов любого метода возвращает null обёрнутый в Nullable-тип возврата, если в самой переменной был null.^0как автор в статье написал, лучше бы для возведения в степень использовали.А тут можно было бы
~0Зачем для этого вообще отдельный термин? Это же самый обычный паттерн-матчинг с нормальной деконструкцией и биндингом сматченных значений в переменные.
Можно было бы обозвать "Pattern matching restrictions have been eased."
Ну, что сказать, печально если ведущий НИИ РАН десятилетиями занимается задачами уровня наследования кружков и прямоугольников от класса Shape и ничем более сложным.
Есть абстрактная идея ООП, а есть её реализации. Поскольку вы хотите не только теорию, но и конкретику, то вам придётся ознакомиться и с реализациями ООП:
Smalltalk — классическая class-based реализация ООП
Erlang/OTP — actor-based реализация ООП
При этом то, что справедливо для конкретной реализации, не всегда справедливо для парадигмы как таковой.
Да в принципе никакое, пока вы сами по себе что-то там пишете, можете хоть своим личным ООП руководствоваться. Но раз взялись писать статью, то потрудитесь хоть немного разобраться в теме, прежде чем писать о ней. И нет, прочитать одну статью на википедии недостаточно.
OMFG, вы читать вообще умеете, я же русским языком написал, что взял синтаксис из вашего примера, чтобы вам понятнее было. Напоминаю:
sendMsg ({куда}, {сообщение});Каждая строка отправляет сообщение конкретному объекту, а все вместе они образуют ряд из 4 объектов (eventLogger, eventValidator, eventEnricher, eventHandler)
О чём вы вообще говорите? Какие миллионы компов всей Земли? Хоть это и происходит, но это вообще не в тему обсуждения. Вы вообще понимаете, что такое горизонтальное масштабирование системы? Или кроме desktop-приложений на Delphi ничего не делали?
Точнее, он определил диапазон:
223/71 < π < 22/7
Если для него взять среднее, то получится 3.1418511