ну вот и замечательно, «имхо» никогда не возбраняется
> жестким и не позвалять глупости человеку
думаю, лучше тоже в «имхо» засчитать ;) к примеру, Python не позволяет расширять стандартные классы, а Ruby (и JS) — позволяют — кто тут прав? Никто, и в то же время — каждый по своему (по своей реализации). C++/Java вообще не позволяют («жёстко, без глупостей человека») — они, может быть, правы? — и да, и нет — особенность реализации, не более.
> Тот же класс Foo, у которого есть метод getSomething
и что? getSomething — обычное свойство-геттер, возвращающее вычисленное значение на основе ста внутренних переменных. Здесь люди спорят (зачем-то ;)) — должны ли быть эти сто переменных недоступными напрямую, или же не обязательно. Кто-то зачисляет это в основу ООП (тогда как это основа абстракции), кто-то — нет. При этом, ещё раз повторю, любая реализация, если захочет и это будет полезным и нужным — может вносить любые коррективы. Private, public, protected — есть эти коррективы, какая-то реализация захотела их внести, посчитав достаточно удобным «сахаром» — все это прекрасно осознают. Я ратую за то, что смысла что-то жёстко категорично отстаивать в данном случае — нет, поскольку не мы создатели этих систем, мы их анализируем, смотрим плюсы и недостатки, не так ли?
Ещё раз, инкапсуляция — это абстракция, чёрный ящик. Всё, не более. Создана исключительно для усиления абстракции (и, как следствие, для повышения надёжности), чтобы пользователь не задумывался о реализации, а видел лишь интерфейс.
Есть жёсткая инкапсуляция (aka private, public и др.) — хорошо, нет — тоже неплохо (своя реализация). Кто называет инкапсуляцию основой ООП — не прав, поскольку, повторю, инкапсуляция вытекает лишь из усиления абстракции (но никак не из паранойи), а абстракцией является ровно всё в программировании (даже при программировании на ассемблере и в hex-кодах — ведь hex-коды — это уже абстракция (и инкапсуляция) сигналов процессору — человеку на надо знать, как эти hex-коды реализованы внутри).
> в примере есть maxSpeed, dSpeed, stopIterate и прочие параметры, у которых нету и не должно быть ни сеттеров, ни геттеров
ну я уже писал выше — данный момент больше вытекает в понятие абстракции (и дальше можно продлить в инкапсуляцию) — обычная функция Math.round(...) — будет использовать тысячи внутренних переменных (и maxSpeed, maxSpeed, и dSpeed, и ещё сто штук) — это есть абстракция (и, как следствие, инкапсуляция), чёрный ящик (никаких private, protected здесь не видно, однако, они, естественно, вполне хороших синтаксический сахар). Сама же жёсткая инкапсуляция — только в головах — те, кто будут использовать Ваши классы — вполне могут открыть исходники и поменять private на public (если захотят). С другой стороны, может быть откомпилированный сервис, и к исходникам доступа нет, тогда минимальный интерфейс наружу (со скрытыми тысячами вспомогательных сущностей, которым нельзя присвоить значение прямо (возможно, dSpeed вычисляется по хитрой формуле внутри)) — это хорошо (система будет стабильней), но самое главное — осознавать, что это дополнение, сахар, но не суть ООП.
> я тупо пытаюсь по-хорошему разобраться в ООП, можете смеяться
делать нечего больше, желание разобраться — это очень хорошо.
> ООП предоставляет больше возможностей, чем прототипирование
Я предлагаю попробовать найти очень большие отличия между, скажем, Python'ом (который слывёт «ООП-ее некуда языком») и JS. Проанализировать их модели (а главное (самое главное) — механизмы) наследования, инкапсуляции и т.д. Если Вы найдёте эти большие отличия, пожалуйста, напишите мне, мне будет интересно.
> расскажите мне, пожалуйста, по какой причине все, нужные и не нужные, методы всех объектов должны «торчать наружу»?
Инкапсуляция — является «сахаром», однако, не основой ООП. Иногда знание, что «так делать нельзя» — есть инкапсуляция (опять же, можно посмотреть инкапсуляцию в Python'e). Подход к ООП-реализациям (коих может быть множество, опять же — если будет обоснование и целесообразность этих особенностей и нововведений), включая сущность инкапсуляции, не должен быть параноидальным. Инкапсуляция — это дополнение, но не главная суть, не ядро. К примеру, обычные функции с точки зрения абстракции являются инкапсулирующими сущностями — человек знает, как вызвать функцию Math.round(...), но реализация её — абстрагирована и инкапсулирована от использующего её (при этом никаких private, protected т.д. здесь не фигурирует).
Сама же суть жёсткого (именно жёсткого) сокрытия — есть «сахар», но не первопричина (хотя, конечно, технологически обоснованный «сахар» — именно поэтому он и появился в различных реализациях ООП). Почему не так в JS — такая реализация.
> есть большие сомнения в том, что можно сделать ЯП без абстракции, полиморфизма, наследования, инкапсуляция и он будет поддерживать ООП парадигму
без абстракции — абсолютно нельзя (всё программирование — есть абстракция и усиление её при прогрессе). Насчёт ООП, — изначально то, о чём сказал я в этом треде — если какая-то реализация вносит корректировки в изначальную модель и обосновывает это — есть ли смысл брать на себя ответственность за утверждения, что «должно быть так и не иначе»? ;)
> насчет Ваших познаний JS мне ничего не известно. а что, не должно бы?
да нет, знаете Вы или нет, по сути не имеет значения, просто Вы сказали, что любите ставить минус тем, «кто авторитетно что-то заявляет»; я тоже считаю, что «важен авторитет истины, а не истина авторитета»; в ключе же JS, да я могу ответить компетентно.
> Предъявите мне наследование в Javascript, если оно есть
мне не нравится подобные позиции; с чего-то, вдруг, люди, что-то отрицающие, всегда считают (безосновательно ;)), что им должны кто-то что-то предоставить. Мы, естественно, поменяемся местами, и это Вы мне предоставите все факты и теорию, что наследования в JS нет, хорошо? ;)
Я лишь натолкну на путь, где можно почитать о JS, и, в частности, о наследовании в JS — стандарт ECMA-262-3.
> в JS наследования нет. Это аксиома.
Что-то имеете против, если я назову это полной чушью?
> Javascript — вполне неплохо, питон — очень поверхностно
Нет, подождите ;) Вы рассуждаете в утверждающем ключе. Как это возможно при знании языков не на глубоком уровне? Чтобы разговаривать на языке утверждения (касательно Javascript, я могу говорить так, да и о Python't тоже) надо знать достаточно глубоко и теорию и практику.
> Попробуйте почитать — может быть и Вы сможете
Спасибо, «оценил» ;)
Попробуйте найти принципиально категоричные отличия Python'a от JS. Если Вам это удастся, покажите, мне интересно.
А приведите пример, если не сложно, в чём принципиальная большая разница наследования в Python'e и JS?
> Разницы не заметно?
В том-то и дело, что разницы Вы практически не увидите вообще никакой (если, конечно, Вы знаете и JS и Python не поверхностно, а достаточно глубоко, чтобы рассуждать, какой язык «мертвый», а какой нет)
А теперь обратим взоры на труды отечественных авторов. Не секрет, что очень много книг в России пишутся различными преподавателями. И, видимо, им совсем не до шуток. Главное, написать умную книгу, чтобы ее рекомендовали к изучению студентам вузов всей страны. Читать наших авторов очень тяжело и скучно.
Зависит от уровня материала. Например, издательство «Питер» на книгах (раньше, во всяком случае) писало уровень (к примеру, «Опытные/Профессионалы»). Если материал книги академический — смысл разбавлять её шутками-прибаутками или чересчур упрощённой лексикой — невелик (поскольку материал автоматом спускается до уровня «среднестатистический/прикладной»). Если Ваша цель — прикладное программирование — не покупайте академические книги, они, как правило, пишутся на глубоком теоретическом уровне (хотя, я не стану говорить об отечественной литературе в этом ключе) и цель их — не объяснить Вам совсем упрощённо на «кухонном» языке, «как написать сайт за два дня», а разобрать аспекты более глубоко.
Я сам сейчас пишу ряд углублённых статей по ECMAscript'у (в частности, по спецификации ECMA-262-3). Естественно, разбавляю сухой стандарт поясняющими примерами. Те, кто желает разобраться глубоко в JS, находят статьи весьма полезными. Однако, также, я вижу иногда комментарии, аля «ой, как сухо...» — как будто не понятно, что статьи не для того, чтобы вы смогли скопи-пастить примеры в свои пригладные проекты? ;)
Рассказать же проще и легче, разбавляя весёлыми историями, — это так же легко (и, поверьте, намного легче, чем глубоко разобраться в технологии и беседовать на её языке), просто не стоит отбрасывать такое понятие как «уровень статей». Естественно, аудитория изменяется обратнопропорционально уровню сложности статей.
ну вот и замечательно, «имхо» никогда не возбраняется
> жестким и не позвалять глупости человеку
думаю, лучше тоже в «имхо» засчитать ;) к примеру, Python не позволяет расширять стандартные классы, а Ruby (и JS) — позволяют — кто тут прав? Никто, и в то же время — каждый по своему (по своей реализации). C++/Java вообще не позволяют («жёстко, без глупостей человека») — они, может быть, правы? — и да, и нет — особенность реализации, не более.
да что Вы? ;) понял-понял.
> Тот же класс Foo, у которого есть метод getSomething
и что? getSomething — обычное свойство-геттер, возвращающее вычисленное значение на основе ста внутренних переменных. Здесь люди спорят (зачем-то ;)) — должны ли быть эти сто переменных недоступными напрямую, или же не обязательно. Кто-то зачисляет это в основу ООП (тогда как это основа абстракции), кто-то — нет. При этом, ещё раз повторю, любая реализация, если захочет и это будет полезным и нужным — может вносить любые коррективы. Private, public, protected — есть эти коррективы, какая-то реализация захотела их внести, посчитав достаточно удобным «сахаром» — все это прекрасно осознают. Я ратую за то, что смысла что-то жёстко категорично отстаивать в данном случае — нет, поскольку не мы создатели этих систем, мы их анализируем, смотрим плюсы и недостатки, не так ли?
Не миксуйте понятия инкапсуляции и композиции.
Ещё раз, инкапсуляция — это абстракция, чёрный ящик. Всё, не более. Создана исключительно для усиления абстракции (и, как следствие, для повышения надёжности), чтобы пользователь не задумывался о реализации, а видел лишь интерфейс.
Есть жёсткая инкапсуляция (aka private, public и др.) — хорошо, нет — тоже неплохо (своя реализация). Кто называет инкапсуляцию основой ООП — не прав, поскольку, повторю, инкапсуляция вытекает лишь из усиления абстракции (но никак не из паранойи), а абстракцией является ровно всё в программировании (даже при программировании на ассемблере и в hex-кодах — ведь hex-коды — это уже абстракция (и инкапсуляция) сигналов процессору — человеку на надо знать, как эти hex-коды реализованы внутри).
ну, «имхо», это хорошо, к тому же, это непротиворечивое «имхо», а вполне (повторю), технологически и идеологически обоснованный «сахар»
ну я уже писал выше — данный момент больше вытекает в понятие абстракции (и дальше можно продлить в инкапсуляцию) — обычная функция Math.round(...) — будет использовать тысячи внутренних переменных (и maxSpeed, maxSpeed, и dSpeed, и ещё сто штук) — это есть абстракция (и, как следствие, инкапсуляция), чёрный ящик (никаких private, protected здесь не видно, однако, они, естественно, вполне хороших синтаксический сахар). Сама же жёсткая инкапсуляция — только в головах — те, кто будут использовать Ваши классы — вполне могут открыть исходники и поменять private на public (если захотят). С другой стороны, может быть откомпилированный сервис, и к исходникам доступа нет, тогда минимальный интерфейс наружу (со скрытыми тысячами вспомогательных сущностей, которым нельзя присвоить значение прямо (возможно, dSpeed вычисляется по хитрой формуле внутри)) — это хорошо (система будет стабильней), но самое главное — осознавать, что это дополнение, сахар, но не суть ООП.
делать нечего больше, желание разобраться — это очень хорошо.
> ООП предоставляет больше возможностей, чем прототипирование
Я предлагаю попробовать найти очень большие отличия между, скажем, Python'ом (который слывёт «ООП-ее некуда языком») и JS. Проанализировать их модели (а главное (самое главное) — механизмы) наследования, инкапсуляции и т.д. Если Вы найдёте эти большие отличия, пожалуйста, напишите мне, мне будет интересно.
> расскажите мне, пожалуйста, по какой причине все, нужные и не нужные, методы всех объектов должны «торчать наружу»?
Инкапсуляция — является «сахаром», однако, не основой ООП. Иногда знание, что «так делать нельзя» — есть инкапсуляция (опять же, можно посмотреть инкапсуляцию в Python'e). Подход к ООП-реализациям (коих может быть множество, опять же — если будет обоснование и целесообразность этих особенностей и нововведений), включая сущность инкапсуляции, не должен быть параноидальным. Инкапсуляция — это дополнение, но не главная суть, не ядро. К примеру, обычные функции с точки зрения абстракции являются инкапсулирующими сущностями — человек знает, как вызвать функцию Math.round(...), но реализация её — абстрагирована и инкапсулирована от использующего её (при этом никаких private, protected т.д. здесь не фигурирует).
Сама же суть жёсткого (именно жёсткого) сокрытия — есть «сахар», но не первопричина (хотя, конечно, технологически обоснованный «сахар» — именно поэтому он и появился в различных реализациях ООП). Почему не так в JS — такая реализация.
без абстракции — абсолютно нельзя (всё программирование — есть абстракция и усиление её при прогрессе). Насчёт ООП, — изначально то, о чём сказал я в этом треде — если какая-то реализация вносит корректировки в изначальную модель и обосновывает это — есть ли смысл брать на себя ответственность за утверждения, что «должно быть так и не иначе»? ;)
> насчет Ваших познаний JS мне ничего не известно. а что, не должно бы?
да нет, знаете Вы или нет, по сути не имеет значения, просто Вы сказали, что любите ставить минус тем, «кто авторитетно что-то заявляет»; я тоже считаю, что «важен авторитет истины, а не истина авторитета»; в ключе же JS, да я могу ответить компетентно.
Вообще, суть инкапсуляции весьма относительна. Никакое предположение не будет истиной в последней инстанции. Кстати, в чём её суть видите Вы?
> а кнопка минус у меня любимая, когда люди авторитетно утверждают
А есть большие сомнения по поводу моих знаний JS?
> я Вас правльно понял
Да нет же, абсолютно не правильно, извините :).
> язык, который будет «идеологически» уметь только числа от ноля до пяти складывать — и заявить, что язык поддерживает парадигму ООП
Демагогия. Она здесь не уместна. Вы же понимаете, о чём я говорю.
мне не нравится подобные позиции; с чего-то, вдруг, люди, что-то отрицающие, всегда считают (безосновательно ;)), что им должны кто-то что-то предоставить. Мы, естественно, поменяемся местами, и это Вы мне предоставите все факты и теорию, что наследования в JS нет, хорошо? ;)
Я лишь натолкну на путь, где можно почитать о JS, и, в частности, о наследовании в JS — стандарт ECMA-262-3.
> в JS наследования нет. Это аксиома.
Что-то имеете против, если я назову это полной чушью?
Нет, подождите ;) Вы рассуждаете в утверждающем ключе. Как это возможно при знании языков не на глубоком уровне? Чтобы разговаривать на языке утверждения (касательно Javascript, я могу говорить так, да и о Python't тоже) надо знать достаточно глубоко и теорию и практику.
> Попробуйте почитать — может быть и Вы сможете
Спасибо, «оценил» ;)
Попробуйте найти принципиально категоричные отличия Python'a от JS. Если Вам это удастся, покажите, мне интересно.
А приведите пример, если не сложно, в чём принципиальная большая разница наследования в Python'e и JS?
> Разницы не заметно?
В том-то и дело, что разницы Вы практически не увидите вообще никакой (если, конечно, Вы знаете и JS и Python не поверхностно, а достаточно глубоко, чтобы рассуждать, какой язык «мертвый», а какой нет)
Да, и, наследование в JS, конечно же, есть ;)
Ничего, ровным счётом. Любая реализация вправе вносить любые коррективы, если они технологически и идеологически обоснованы.
>… Python — не требуют подпорок для ООП
А Вы видели большую принципиальную разницу между ООП-моделью Python'a и Javascript? ;)
Зависит от уровня материала. Например, издательство «Питер» на книгах (раньше, во всяком случае) писало уровень (к примеру, «Опытные/Профессионалы»). Если материал книги академический — смысл разбавлять её шутками-прибаутками или чересчур упрощённой лексикой — невелик (поскольку материал автоматом спускается до уровня «среднестатистический/прикладной»). Если Ваша цель — прикладное программирование — не покупайте академические книги, они, как правило, пишутся на глубоком теоретическом уровне (хотя, я не стану говорить об отечественной литературе в этом ключе) и цель их — не объяснить Вам совсем упрощённо на «кухонном» языке, «как написать сайт за два дня», а разобрать аспекты более глубоко.
Я сам сейчас пишу ряд углублённых статей по ECMAscript'у (в частности, по спецификации ECMA-262-3). Естественно, разбавляю сухой стандарт поясняющими примерами. Те, кто желает разобраться глубоко в JS, находят статьи весьма полезными. Однако, также, я вижу иногда комментарии, аля «ой, как сухо...» — как будто не понятно, что статьи не для того, чтобы вы смогли скопи-пастить примеры в свои пригладные проекты? ;)
Рассказать же проще и легче, разбавляя весёлыми историями, — это так же легко (и, поверьте, намного легче, чем глубоко разобраться в технологии и беседовать на её языке), просто не стоит отбрасывать такое понятие как «уровень статей». Естественно, аудитория изменяется обратнопропорционально уровню сложности статей.