Уголок программиста

[pse]

Не очень понял про какую документацию и спецификацию вы говорите, тем более официальную, но для ООП попробуйте начать с классики банды четырех: Приемы объектно-ориентированного программирования. Паттерны проектирования
https://docs.google.com/file/d/0B6GuCegBf3X3Tm1rZl9BUTduQm8/edit
Понимание и владение паттернами ООП ИМХО выводит человека на другой уровень программирования.
Образно выражаясь, в документации у каждого ЯП по ООП написан алфавит. И после изучения только алфавита программист собирает какие-то несвязные последовательности букв из этого алфавита.
А после изучения паттернов начинает складывать из этих букв слова, предложения и дело доходит до стихов и рассказов, поэм и т.д.
[DOUBLEPOST=1524460445][/DOUBLEPOST]Но это опять таки общепринятые приемы, рекомендации так сказать, которые можно принимать, а можно и нет. В конечном итоге, все равно в процессе поиска каких-то решения приходишь к этим паттернам через кровь и пот. Возвращаясь к примеру естественных языков, на латинском алфавите основывается очень много разных языков. И на каждом из них есть книги, стихи и т.д.
[DOUBLEPOST=1524460651][/DOUBLEPOST]И лучше конечно же использовать некие стандартные приемы, понятные большинству. Например, когда продумываешь какое-то решение, то думаешь примерно так - Вот здесь я использую паттерн строитель, а здесь у меня будет фасад. А тут подошел бы синглтон. И каждый, кто потом будет прикасаться к коду и знаком с паттернами - будет видеть их в коде и ему будет легче понять чужой код. Как-то так ИМХО.

 

[Alex Longard]

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

 

[pse]

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

https://ru.wikipedia.org/wiki/Парадигма_программирования

 

[pse]

Есть еще вот такая вот статейка:
https://habrahabr.ru/post/147927/
Что скажете?

 

[pse]

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

 

[PianoIst]

Есть еще вот такая вот статейка:

ну и зачем вы это сделали? Я ж уже читал по лету все комменты, ща опять по второму кругу на час залип....

 

[pse]

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

 

[Alex Longard]

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

 

[SuperDroid]

други, вы можете вкратце ответить (без ссылок, своими словами): Python чем категорически пока еще не может заменить собой полностью C++

 

[Altschuller]

@SuperDroid а разве не может?

 

[bytie]

други, вы можете вкратце ответить (без ссылок, своими словами): Python чем категорически пока еще не может заменить собой полностью C++

@SuperDroid а разве не может?

Скоростью как минимум. Насчёт шаблонизированных лямбд не уверен

 

[Alex_V]

вот из-за толкового ООП я и подсел на питон)))

В питоне, вот как по мне, не хватает разграничения областей видимости методов и атрибутов.

Кстати даже на структурно-процедурных языках реализуют парадигму ООП, так что языки в которых изначально присутствует такая инструкция как "class" только частично облегчают издевательство над кодом)))

Ну вот, например, Lua. Там ООП нет, но его можно сэмулировать. При этом существует куча реализаций этого дела, каждая со своими тараканами, каждая библиотека норовит добавить свою реализацию. Во щастье-то!

P.S. Кстати, про питон. Щас пытаюсь кой чего сваять с некоторым прицелом на кроссплатформенный GUI. Позиция буриданова осла между Kivy и QT. Мож кто что посоветует?

 

[Alex Longard]

@Alex_V, кроссплатформой незанимался но видел кучу хороших отзывов за киви, особенно на мобильных платформах. Сам пока не ковырял.
В луа кстати метатаблицы это уже нехилый шаблон для парадигмы ООП, кажется это было содрано из smalltalk, который сам по себе "объект из объектов" ))


@SuperDroid, недостатки питона: не умеет компилировать в dll и exe, драйвера под операционку ненаписать, и критические по скорости выполнения участки кода приходится писать в виде .pyd модулей на компилируемых языках.

Я в свое время тоже свысока поглядывал на питон и улыбался "как на интерпретаторе можно что либо написать, это же игрушка для лохов и пятистрочный скрипт повесит смарт", а сейчас понимаю что авторитетным стало для меня то что питон используют HP, Intel, Google, Nassa.
Не думаю что там сидят лошары, да и требования в эти фирмы на работу - знание питона и хотя бы пару дополнительных пакетов.

@bytie, питон на 12% тормознее чем C++ и на 28% чем C. При современных мощностях процов это заметно только при отрисовке графики или статистических пакетах.
Сейчас джава со своим байткодом показывает очень плохие результаты по скорости и сильно проигрывает питону. На хабре есть прошлогодняя статья с тестами десятка языков от фасма до питона, последний на четвертом месте по скорости))))

 

[Alex_V]

но видел кучу хороших отзывов за киви, особенно на мобильных платформах

Ну я вот начал ковырять. Нарвался на баг - как минимум под виндой (а винда интересует в первую очередь, остальное - как фишка ляжет) из-за особенностей отрисовки, заложенных в ядро, можем получить ситуацию, когда текст будет выглядеть размытым. Для GUI библиотеки - неприемлемо. Баг, причем, давно известен разработчикам, но делать с этим ничего не пытаются. Способ поправить это вот прям в ядре есть, но говорят, что негарантированный и может что-нибудь другое поломать. Вот теперь думаю насчет QT с его QML.

 

[Zildjian]

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

 

[Alex Longard]

@Alex_V, тогда стоит попробовать SDL2 или Iup. Апи у них довольно удобное. QT лично мне ненравится, некантачит со скринридерами, тяжелые либы (под 50 метров), визуализация графика или спектрограммы такая что можно успеть сделать кофе и упится в хлам.
Обычно с QT извращаются когда часть интерфейса на самом QT а что-нибудь скоростное рисуют в канвасе средствами винапи или сторонних либ.

 

[Zildjian]

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

Это что ж вы такое рисуете и каким способом, что оно столько времени рендерится?

 

[Alex_V]

Собственно, зачем меня в эту степь вообще понесло. Есть желание написать некую рулилку синтом, но готовые решения типа ctrlr не устраивают из-за ограниченности возможностей по построению гуя. Взять тот же JUCE и написать все на C++ можно (есть еще некоторые фреймворки и языки, но не везде всё устраивает), но скриптовый язык несколько упрощает построение чего-нить расширяемого. Возможность часть интерфейса сделать декларативным - тоже в плюс в этом смысле. При этом супервысокая производительность не особо и нужна - нужно всего лишь гонять midi данные.

 

[Удалённый пользователь 75985]

Собственно, зачем меня в эту степь вообще понесло. Есть желание написать некую рулилку синтом, но готовые решения типа ctrlr не устраивают из-за ограниченности возможностей по построению гуя. Взять тот же JUCE и написать все на C++ можно (есть еще некоторые фреймворки и языки, но не везде всё устраивает), но скриптовый язык несколько упрощает построение чего-нить расширяемого. Возможность часть интерфейса сделать декларативным - тоже в плюс в этом смысле. При этом супервысокая производительность не особо и нужна - нужно всего лишь гонять midi данные.

Такое есть на csound - http://cabbageaudio.com/
А чем Ctrlr не устроил? В самом juce в принципе всё то же самое почасти gui

 

[Alex_V]

А чем Ctrlr не устроил?

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

В самом juce в принципе всё то же самое почасти gui

Внешне - во многом так, но решение на чистом C++ было бы лишено некоторых недостатков ctrlr. Ну и плюс вроде появляется возможность переноса на мобильные платформы.

 

[Удалённый пользователь 75985]

Тогда есть смысл сразу начать писать на чистом C++ с использованием juce, если нужны именно они. Разве есть ещё варианты?

 

[Alex_V]

Тогда есть смысл сразу начать писать на чистом C++ с использованием juce, если нужны именно они

JUCE - это не принципиально, это просто в данном применении одна из кроссплатформенных GUI библиотек, т.к. мне ни vst, ни обработка аудио не нужны. Все нужное реализуемо даже на питоне. Собственно, некое подобие proof of concept базовых вещей я для себя на Python + Kivy наваял и благополучно разобрал уже. Дальше буду думать, с чем таки лучше связываться - с QT или Kivy. Под QT можно потом многое переписать на чем-то, отличном от питона.

 

[SuperDroid]

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

 

[Zildjian]

Это вопрос из раздела религиозного срача "функциональное программирование vs объектно ориентированное программирование vs любая-другая-парадигма" и однозначного ответа не имеет. Могу рассуждать только на собственном опыте, вследствие чего окажусь втянутым в вышеупомянутый срач)

 

[pse]

Казалось бы куда лучше, но есть ведь и ООП - а вот чем он лучше подпрограмм?

В каждом подходе есть свои плюсы и минусы. Процедурный подход - отличная вещь. Но концепция ООП позволяет гибче переиспользовать код. но это и ахилесова пята его - код становится труднее понять в некоторых моментах. Обычно усложнение происходит при разрастании количества классов, их взаимном влиянии друг на друга, так называемая связность классов. Наследование добавляет гемора, но в некоторых случаях наследование - то что доктор прописал. В целом мне нравится подход ООП. Полиморфность, наследование, скрытие за абстракциями интерфейсов реализации и т.п.
[DOUBLEPOST=1524597366][/DOUBLEPOST]У меня на работе язык сочетает в себе все прелести процедурного кода с ООП. Можно писать как процедуры-функции, так и пользоваться объектами. Весь легаси код написан в процедурном исполнении, поскольку ООП появилось сравнительно недавно в последних версиях языка, но классы все больше и больше проникают в проект)))
[DOUBLEPOST=1524597578][/DOUBLEPOST]

Полиморфность, наследование, скрытие за абстракциями интерфейсов реализации и т.п.

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

 

[Alex_V]

Казалось бы куда лучше, но есть ведь и ООП - а вот чем он лучше подпрограмм?

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

 

[pse]

В общем я за гибрид в религиозном споре)))
[DOUBLEPOST=1524597939][/DOUBLEPOST]

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

Согласен, пока не будет огромного проекта и смотришь на простенькие примеры типа Hello world пофигу что использовать, но когда сложность проекта большая, тут уж так просто не решить, что лучше. В идеале и то и то бы иметь. Один черт гемора предостаточно везде будет.
[DOUBLEPOST=1524598206][/DOUBLEPOST]Есть еще один момент - скорость работы с классами обычно ниже, чем с процедурами. Для них необходимо выделение памяти по иерархии наследования, всякие там конструкторы, деструкторы...в общем куча всякого г...на вызывается. Виртуальные методы, перекрытые методы, рефлексия наконец. Все это очень затратно в плане тактов процессорного времени.

 

[Alex_V]

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

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

 

[pse]

@Alex_V, Опишу свой опыт горький. Как-то заюзал я в одном проекте с базами данных, который мы с другом вместе пилили с нуля, связку C#+Nhibernate+PostgreSQL. База получилась не очень большая, всего-то 35 связанных таблиц. Ну и для NHibernate пришлось аналог базы в объектах налепить(для отображения базы данных в ООП, по другому то С# не понимает, только объекты). В принципе я доволен скоростью разработки, без особого гемора в части SQL, за него хибернейт отвечал, но встала огромная проблема с расходом памяти. Это жесть какая-то. NHibernate вытягивал базу по ссылкам практически всю в память компа, собирая граф объектов. Бился я бился с расходом, но так и не победил((( Программа стартует и сразу видно, как свободная память уходит. Сотнями мегабайт))

 

[Alex_V]

@pse, в любом подходе главное - не упираться в технологии ради технологий. Я не могу сказать ничего про эффективность всяких ORM, т.к. никогда этим не пользовался. При работе с БД предпочитаю классический подход. Таблицы + некое процедурное API к ним. И базы так чуток посложнее. Ща глянул свой основной рабочий проект (ему уже много лет) - более 1200 таблиц, 6000 с лишним процедур. Все это без каких-либо ORM нормально живет.