К сожалению, с python, так и не посидел плотно, но представляю тот ужас, если в классе 100 переменных, 90% из которых _name + точно также с методами, свойствами, событиями и прочими наворотами. Так и посидеть можно. Может к этому можно привыкнуть, но для меня было бы дико.
Обычно если в классе 100 переменных, то этот класс уже нужно дробить. Вообще комментарии никто не отменял, если код хреново оформлен, то тут уже ничего не поможет.
см. пост выше. некоторые проекты вообще обходятся без классов и инкапсуляции, но при этом используют ООП, к примеру - Blender, написан он на Си.
Не спорю, что на разных яп все по-разному. Я могу с уверенностью говорить про C# и Java. И для меня новое открытие - C вдруг стал поддерживать ООП? Чта
Цитата
Обычно если в классе 100 переменных, то этот класс уже нужно дробить. Вообще комментарии никто не отменял, если код хреново оформлен, то тут уже ничего не поможет.
На счет кол-ва образно выразился. Я не раз слышал, что на питоне хорошо реализовано ООП, но после нашей беседы оно уже не кажется таким радужным. После устоявшейся многолетней практики сокрытия, именования и других действий над чем-либо, увидеть _name в public для меня дико.
И для меня новое открытие - C вдруг стал поддерживать ООП? Чта
на ООП можно писать хоть на ассемблере, можно реализовать и полиморфизм и инкапсуляцию, другое дело что это будет довольно геморно. ООП - это методология программирования, кода говорят что язык программирования ООП, это означает что он заточен под эту методологию.
Добавлено (12 февраля 2016, 23:18) --------------------------------------------- То же самое и с функциональными яп, С++ к примеру не является функциональным яп, но никто не запретит мне написать свой фреймворк, который будет чисто функциональным, но при этом я все это могу делать с использованием классов (в подробности вдаваться не буду, если интересно погугли про перегрузку оператора () ), но при этом он не будет ООП, он будет функциональным, но другое дело что я запарюсь это все реализовывать, да и компиляторы функциональных языков программирования лучше оптимизурет такой код, я лучше возьму какойнить Haskell для этих целей.
Добавлено (12 февраля 2016, 23:33) --------------------------------------------- Вообще инкапсуляция — это в первую очередь абстрагирование от реализации. т.е. по сути инкапсулировать функцию нужно для того, что-бы её можно было ИЗМЕНИТЬ. Не меняя остальной код. Ну например ты юзаешь мою сортировку пузырьком, а я прочитаю Кнута, узнаю, что пузырёк == говно, и поставлю qsort. Когда ты в следующий раз соберёшь свою программу, ты увидишь, что она стала быстрее. Но для этого мне надо скрыть от тебя мою реализацию, что-бы ты не смог её менять. Иначе, своим qsort'ом я поломаю твой код(который думает, что это — пузырёк). Сокрытие тут я бы понимал как замену явных вызовов каких то внутренних специфичных методов на вызов одного интерфейсного метода. Т.е. снаружи нет необходимости разбираться в реализации, а не то что реализация скрыта так что ее не увидеть.
ИМХО private следует понимать как НЕ НУЖНО ТУДА ЛЕЗТЬ. Не потому что это «нельзя» и «запрещено», а потому, что это в любой момент могут переделать.
Сообщение отредактировал Xakep - Пятница, 12 Февраля 2016, 23:44
Lapish, Xakep, как модификаторы доступа влияют на использование оперативной памяти(если влияют)? Объясните новичку, плиз.
Вообще никак не влияют. Если ты начнешь писать геттеры/сеттеры где не надо, то там уже лишние вызовы функций пойдут, следовательно дополнительные безусловные переходы, что медленнее чем прямой доступ к переменной.
Xakep, на том же PABC.net'е прописывать private прямо в код программы не имеет смысла. Менять данные всё равно можно будет, и тот кто захочет, тот поменяет. Только если я в модуле это сделаю, будет 100% гарантия. А если у меня монолитный код, то этот private как я понимаю в PABC вообще не нужен. Вот в качестве банального примера:
Код
unit MTest; type clNum=class private Num: integer; public constructor create(); begin end; procedure PrintNum; begin writeln(Num); end; end; end.
Код
uses MTest; var ONum: clNum; begin ONum:=new clNum; //ONum.Num:=1; - разумеется не увидит эту переменную. ONum.PrintNum; ONum:=nil; end.
Потому вся эта инкапсуляция и казалась мне сомнительной. Да и вообще фиг знает где применять. Наблюдатель
Сообщение отредактировал ArromanFox - Суббота, 13 Февраля 2016, 00:35
Xakep, на том же PABC.net'е прописывать private прямо в код программы не имеет смысла. Менять данные всё равно можно будет, и тот кто захочет, тот поменяет. Только если я в модуле это сделаю, будет 100% гарантия. А если у меня монолитный код, то этот private как я понимаю в PABC вообще не нужен.
Ну да логично, в примере ты написал код внутри класса, класс видит свои private методы/переменные, а другие классы не видят.
ЦитатаArromanFox ()
Потому вся эта инкапсуляция и казалась мне сомнительной. Да и вообще фиг знает где применять.
Xakep, а если же в монолитной писать этот приват, то толку ноль. Всё равно я эти данные в основной части программы могу спокойно изменить и он их спокойно видит.
ЦитатаXakep ()
я выше большой пост про это написал.
Извиняюсь, не ожидал добавлений) Две вкладки открыто было, и одну не обновлял. Наблюдатель
Сообщение отредактировал ArromanFox - Суббота, 13 Февраля 2016, 00:47
Xakep, а если же в монолитной писать этот приват, то толку ноль. Всё равно я эти данные в основной части программы могу спокойно изменить и он их спокойно видит.
Xakep, тем не менее они мне необходимы. Сейчас вот например учусь на примере текстовой игры (IF с маленькими вкраплениями рогалика) и понимаю, что некоторые игровые эмм... элементы без классов организовать геморно, с учетом того, что будет достаточно рандома. Хоть и возможно, но ООП всё таки для общего развития надо освоить. Просто пытался определиться нужно ли мне следовать парадигме используя модификаторы доступа. Прихожу к выводу, что конкретно в моём случае не нужно. Но знать это всё равно необходимо на будущее. Наблюдатель
Сообщение отредактировал ArromanFox - Суббота, 13 Февраля 2016, 01:10
Вообще лично я считаю, все эти классы, пакеты, наследование и прочие вещи сделаны в первую очередь для удобства. Представьте, что значит писать весь код игры, весь его функционал в одном файле, а если это рпг? Да при первых 500+ строк запутаешься сразу во всем(не говоря о количестве функций, переменных, сеттеров/геттеров и прочего). Но что делает ооп? Он дает преимущество - разбить проект на отдельные части, обеспечивает возможность создавать удобную и легкочитаемую архитектуру проекта, где в свою очередь каждый игровой модуель имеет свое личное представление. Всё зависит от того, как грамотно ты реализуешь, как тут привыкли называть паттерн - шаблон. Я 3 раза движок игры переписывал с 0, уходил так сказать от глупой архитектуры, игнорируя многие правила ооп(несмотря на том, что проект все же был разбит на кучу классов), что приводило к бесчисленным подводным камням, которые мало того, что найти надо было, да еще и приходилось исправлять код во многих классах. В общем гемороя было до жути. Не все дается с первого раза, особенно когда учишься сам, без институтов и колледжей. Нельзя просто так взять и создать идеальный проект с первого раза. Приходится постоянно что-то исправлять, читать доки, нарабатывать опыт, практиковаться, совершать неизбежные ошибки и исправлять их. В общем дело это кропотливое и если бы у меня было дикое желание написать статьи об этом, я бы еще годика 2-3 практиковался и только потом бы, задумался над тем, чтобы написать хотя бы одну грамотную статью без ляпов и косяков. Кубариум Rise of the dark lords
Сообщение отредактировал Эргалон - Суббота, 13 Февраля 2016, 02:12
Xakep, можно конечно все сделать, если сильно захотеть, но следуя КОП(Костыльно-ориентированное программирование). Перегрузку операторов я всего пару раз использовал да и то когда изучал их. И все. За 5 лет не было ни одной задачи, где я их использовал.
Xakep, можно конечно все сделать, если сильно захотеть, но следуя КОП(Костыльно-ориентированное программирование).
Смысл моего поста походу Вы не понял Естественно на C++ нормально мыслящий человек не станет писать в функциональном стиле, но писать на Си в ООП вполне себе нормальная практика, я к тому что ООП - это методология программирования, а не что-то что вшито в сам язык программирования.
ЦитатаLapish ()
Перегрузку операторов я всего пару раз использовал да и то когда изучал их. И все. За 5 лет не было ни одной задачи, где я их использовал.
Их много где можно использовать - функторы, предикаты, математические объекты какие-то....
ЦитатаЭргалон ()
Не все дается с первого раза, особенно когда учишься сам, без институтов и колледжей.
Я тут читаю все это и понимаю... Или это я выходит что ничего не объяснил или это уже углубленная практика.
Добавлено (14 февраля 2016, 13:45) --------------------------------------------- Я тут подумал над словами Lapish, Xakep, и да. Эти темы я незнаю закрывать или нет. Знаю то, что выпущу статьи в формате Word'a. Книгу считай. Но пока все же да, немного подготовлюсь к этому. Хотя скорее всего я закрываю эти статьи на GcUp Чтобы AlexRabbit опять прикопался что я неудачник т.к плодить темы не камильфо + у нашей команды сейчас идет подготовка к одному проекту. Игре. Ну, а вечером дам исходники змейки .D Знающие люди пусть покопаются :) И тему я прошлую закрою, а эту нет. По одной причине... Сюда будете ради вашего скорее всего интереса вопросы писать по Java .D Проверить то знания надо
Alfe, да, темы плодить не имеет смысла. Достаточно одной. На каждый урок сделай doc. И перед каждым уроком по максимуму читай. Но... новичков как раз не следует сразу же грузить углубленными знаниями. Да, может некоторые знания и упрощают разработку, не смотря на сложность понимания, но в начале должно быть только то, что доступно пониманию для новичка. Но сам при этом получай новые знания, чтобы улучшать качество своих уроков. Наблюдатель
ArromanFox, я лучше подтяну свои знания, манеру подачи и готовый выйду в бой :)
Добавлено (14 февраля 2016, 22:23) --------------------------------------------- Для тех у кого есть Java моя змейка посвящается :) Тык Мало того это "первая игра", так еще и на голяке java
Добавлено (14 февраля 2016, 22:29) --------------------------------------------- Как поиграйте - отпишитесь
Естественно на C++ нормально мыслящий человек не станет писать в функциональном стиле, но писать на Си в ООП вполне себе нормальная практика, я к тому что ООП - это методология программирования, а не что-то что вшито в сам язык программирования.
