То есть если у нас есть класс, у которого все поля публичные - то он не класс, а структура?
Или наоборот, у нас есть структура, но есть соглашение, что напрямую работать с ней нельзя, а надо через getter/setter/какие-то другое функции - вот и инкапсуляция.
Лапши на COBOL асме перле почитай, потом «тяжпромпроцедурного программирования» на цешке с кашкой свичей на неск. экранов, макросов и копипастой, выходами из вложенных циклов по goto, — потом что-нибудь «в меру» объектное, поймешь разницу :)
Дык... я вынужден. Хотя в целом не жалуюсь. Инструмент есть, работа налажена. Ну не орать же «все гавно, надо переписывать!». Печка сложена, пирожки пекутся.
не. он может быть валиден для старпёров которые интуитивно жопой чуят код, и поэтому не задумываются о нормальных определениях
а мне как неофиту хочется взять и прочитать кто что означает
тут дело не в старпёрстве. А в том, что если взять процедурный и ООП код, то второй будет читаться проще, вносить изменения в него будет проще. Возможно, не всегда, но, имхо, в большинстве случаев
А все обучение строится на «скачке понимания». (Научить чему-то людей вообще нельзя — это изнутри приходит) Ты сначала что-то пробуешь руками — вроде получается... Потом начинаешь понимать, что получается какая-то лажа — когда кот твоего маленького «проэкта» превышает пороговое значение понимабельности полученной «кашки» через две недели/месяц/год, вызывая недоумение «кто блжад это написал? Как, я и написал?» — а вносить изменения становится накладно :) Начинаешь интересоваться, а как «более лучдшы говнокодить» и почему то что раньше получалось - получалось херово. Т.е. тебе было сначала норм — а потом кто-то посмотрел в твой кот... И в лучшем случае ничего не понялв более лучшем это был ты — через месяц, когда почитал умных книжек где разобраны «типичные ошибки» :))) Чувство меры приходит именно с опытом — без него ты и в ООП будешь городить монстров.
П — существительное от причастной формы глагола, то есть процесс над чем-то. ОО это определение, в данном случае подход к процессу. Таким образом, ООП это процесс программирования кем-то чего-либо с использованием понятия объекта как базового блока (оно уже есть в этом треде). То, как этот подход будет выражен синтаксически и структурно, имеет значение только с практической точки зрения.
Не знаю, что он имел ввиду под модулем, но когда в Lua надо скрыть данные*, то я юзаю:
local M = { } -- module
local pp = setmetatable({ }, { __mode = "k" })
function M.new()
local object = { } -- public
pp[object] = { } -- private
return object
end
function M.foo(object)
pp[foo].private_var = 1
end
return M
Здесь pp чисто локальная для модуля таблица и извне доступна только через отладочный модуль.
* - не с целью запретить макакам что-то сделать, а чтобы при обходе ключей не светились, например
Это не важно. Важно то, что то что отделяет ООП от других парадигм, не имеет ничего общего с тем, что отделяет теокат от теоретико-множественного подхода (а это категории, естественно, кэп подсказывает, что именно в этом основное отличие, в ТМ категорий нет)
И то и другое выразимо в ООП и является частными случаями, не более того.