ООП в LUA и профит от него

Страницы: 1
RSS
ООП в LUA и профит от него, ООП в LUA и профит от него
 
Добрый день. Кто может разъяснить (может даже с обоснованием) зачем ООП в LUA? Т.е. какой от него профит и действительно ли он так нужен? Я видел кучу примеров. Сам я знаком и очень хорошо с традиционным ООП на языках, изначально заточенных под это. Примеры на LUA видел разные и честно скажу не сразу одуплил. Отсюда  вопрос: есть ли вообще смысл это понять и внедрять  каждом проекте, что это реально дает: экономия памяти, скорость, еще что-то?
 
Цитата
Виталий написал:
какой от него профит
Безотносительно к луа ООП понижает цикломатическую сложность кода в целом, позволяя писать куски кода разным людям или одному в режиме "по частям" и упрощая формальный анализ и покрытие тестами. Профит только в этом, все остальное рекламное бла-бла, в том числе НЕ быстрее, НЕ меньше памяти и даже НЕ меньше кода как такового (а обычно сильно больше). Соответственно, если вас данная проблематика не тревожит, можете не загоняться. По поводу "зачем оно есть именно в луа" - ну так вышло, что можно извернуться и сделать ООП, чего ж не возопить "у нас есть ООП".
 
По большей части я спрашивал именно касательно луа, а не ООП в целом. Кстати, а откуда Вы взяли эти данные/статистику? Есть какие-то исследования на эту тему? Так-то я никогда не замерял количество кода, единственное замечал, что в некоторых проектах на том же php, сильно проще писать без ООП, если не используешь фреймворки. Код выходит понятнее и реализуется все это куда быстрее. Но спасибо за Ваш ответ, в целом близко к моему мнению. Сам писал без ООП, недавно попался проект на ООП и честно говоря я так и не понял: нафига?!
Если у кого есть еще какие мнения - выслушаю.
 
Цитата
Виталий написал:
Кстати, а откуда Вы взяли эти данные/статистику? Есть какие-то исследования на эту тему?
Это просто очевидно. Возьмем C против C++, например. По памяти добавляются RTTI, таблицы виртуальных функций, таблицы исключений, код вызова деструкторов и конструкторов, не говоря уже о поддержке всего этого со стороны стандартной библиотеки. По скорости добавляются виртуальные вызовы, оверхеда немного, но он есть, а в случае dynamic_cast или множественного наследования оверхед уже значительный. В случае с луа ООП делается через метатаблицы, по памяти это плюс сама метатаблица, по скорости это плюс доступ к ней.

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

читайте про АТД и затем про ООП. это фундаментальные вещи.

Цитата
Виталий написал:
Сам я знаком и очень хорошо с традиционным ООП на языках, изначально заточенных под это.... Отсюда  вопрос: есть ли вообще смысл это понять и внедрять  каждом проекте, что это реально дает: экономия памяти, скорость, еще что-то?

видимо пора перейти от поверхностного знакомства к системному изучению ... иначе так и будет - только ошибочное самомнение.
 
В Lua, все же, прототипная модель ООП (https://ru.wikipedia.org/wiki/Прототипное_программирование). Если быть точным, в Lua все построено на таблицах. Поэтому думать о расходе памяти и оптимизировать код надо всегда (слабые таблицы).
Поэтому Классы в Lua решают больше задачу создания некой сущности на основе шаблона. Что бывает удобно. Но все то же можно сделать и без оного, придется просто сделать больше переменных.
 
Цитата
новичок написал:
Цитата
Виталий написал:
Если у кого есть еще какие мнения - выслушаю.
тут нет никаких мнений, а либо есть знания, либо их нет - как в Вашем случае.

читайте про АТД и затем про ООП. это фундаментальные вещи.

Цитата
Виталий написал:
Сам я знаком и очень хорошо с традиционным ООП на языках, изначально заточенных под это.... Отсюда  вопрос: есть ли вообще смысл это понять и внедрять  каждом проекте, что это реально дает: экономия памяти, скорость, еще что-то?

видимо пора перейти от поверхностного знакомства к системному изучению ... иначе так и будет - только ошибочное самомнение.
Вы, видимо, один из тех "гуру", которые все знают, но ничего не могут объяснить. А может и не знают даже, но делают вид )) Вопрос был задан конкретно: что дает эмуляция ООП в LUA (это именно эмуляция), причем даже указал конкретно ключевые подвопросы: скорость, память и т.д. Изучать здесь нечего, по крайней мере по ООП в общем. Речь идет конкретно о ЛУА и эмуляции ООП в ЛУА! Форумы придуманы для получения быстрого ответа на вопрос - это комьюнити, где можно получить быстро ответа и сэкономить кучу времени и потратить его на реализацию проекта/задачи, а не зарываться в мануалы, книги и т.д. Если все будут самостоятельно рыться в книгах в поисках ответа - зачем тогда форум и где же вы тогда будете разводить срач?! )))
 
Ну и для примера. У меня в одной из библиотек реализован класс "Ордер". У него есть методы и свойства общие для ордеров.
У него два наследника - "Лимитные ордера", "Стоп ордера". У них уже есть свои, характерные именно для них, методы и свойства.
Это позволяет работать с ордером как с объектом, а не просто как строка в таблице Квика. А методы позволяют реализовать интерфейс к ордеру, в понятных и общих терминах.
 
Цитата
Nikolay написал:
Ну и для примера. У меня в одной из библиотек реализован класс "Ордер". У него есть методы и свойства общие для ордеров.
У него два наследника - "Лимитные ордера", "Стоп ордера". У них уже есть свои, характерные именно для них, методы и свойства.
Это позволяет работать с ордером как с объектом, а не просто как строка в таблице Квика. А методы позволяют реализовать интерфейс к ордеру, в понятных и общих терминах.
Ну да, суть я понял. Скорее для удобства все это дело
 
Цитата
Виталий написал:
Вы, видимо, один из тех "гуру", которые все знают, но ничего не могут объяснить.
со стороны виднее

Цитата
Виталий написал:
даже указал конкретно ключевые подвопросы
мой пост был с учетом уже имевшегося ответа от Антона.
Цитата
Виталий написал:
сэкономить кучу времени и потратить его на реализацию проекта/задачи, а не зарываться в мануалы, книги
именно это мной и имелось ввиду. это грубая ошибка. нет сомнений.

Цитата
Виталий написал:
зачем тогда форум
например, чтобы понять неправоту и исправится. или не понять.

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

Цитата
Виталий написал:
А может и не знают даже, но делают вид
много лет мну объяснял друзьям и близким что открывашка - жулики, а кризис будет жесткий.

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

jedem das seine.
 
Цитата
Виталий написал:
Скорее для удобства все это дело
Не совсем. Начиная с некой размерности задачи попытка "в лоб" закодить будет сродни попытке построить "конечный автомат всея квика", то есть (не) получится нечто необозримого объема. Переход тксть количества в качество произойдет и хошь не хошь придется ООП использовать.

Цитата
новичок написал:
именно это мной и имелось ввиду. это грубая ошибка. нет сомнений.
Согласен. На форуме лучшее, что можно получить, это ключевики, куда искать. Все равно сколько-нибудь серьезную тему одним-двумя постами не раскрыть.
Страницы: 1
Читают тему
Наверх