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


Это сообщение отредактировал(а) Anton Vatchenko - 28.8.2008, 15:14

Добавлено через 1 минуту и 2 секунды
Только непонятно зачем данные-члены делать public. 

Пардон, забыл статик в первом классе... А публичные - чтобы видеть извне.

это и есть принципы джавы? 

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

Вообще, лучше бы уточнить, чего конкретно ты хочешь добиться. 

Вообще в любом ооп по лекциям требуется писать так, чтобы было красиво и медленно. Есть места, где такого делать не стоит (не все же сводится к офисным приложениям).

А требуется делать так, чтобы у меня были объекты N разных типов (у меня N классов). Некоторые объекты visible, некоторые нет (ясно что visible относится к классам, поэтому если объекты относятся к одному классу, они все видимые скажем). Большинство видимые, поэтому главный класс visible = 1, и лишь в некоторых visible = 0.

Чтобы потом экземпляр.visible возвращал правильные значения.

Т.е. ты утверждаешь, что если сделать все данные-члены открытыми, то приложение будет работать быстрее? Ты не прав. Простейшие геттеры заменяются прямым обращение самим компилятором при оптимизации по скорости. К тому же есть inline. 




Здесь нельзя использовать static-данные. Они ведь общие для всех объектов. Скажем, будет у тебя 9 видимых объектов класса A, один ты решишь сделать невидимым, обнулив переменную visible. В итоге получишь, что все объекты, так или иначе, связанные с этой переменной станут невидимыми.

Создай простой флаг visible типа bool, размести его в private секции и работай как обычно. Что тебя смущает то?

Это сообщение отредактировал(а) W4FhLF - 28.8.2008, 16:08

Так я ж сказал что все объекты одного типа либо видимые, либо нет. Другими словами изначально (то есть const) известно, что (возьму пример уже свой) косяк рыбы невиден для игрока (так как под водой), а дерево видимое. Ну хоть косяки окуней, хоть лосося, хоть в море хоть в реке - они все РЫБА, и они невидимые, а деревья хоть дуб хоть еще что-то - все ДЕРЕВЬЯ, и они видимые.

Интерестно кто такое сказал что "не рекомендуется", стандарт С++?
вообще давайте подумаем почему член класса делать public не гуд
 - Пользователь класса может изменить содержание членов класса, и не более того, так вот 
Anton Vatchenko , привел пример где пользователь менят содержимое поля класса (visible) что в этом плохого?
Может быть потому что он не делал вызов функции?  

кроме стандарта есть еще куча литературы от неглупых людей + собственный опыт
заново объяснять, чем хороша инкапсуляция, не очень хочется
достаточно доступно объяснено в Новых сложных задачах на C++ Саттера (задача 17)

Люди, не спорьте. Просто объясните как реализовать то, что я указал.

Так уже тысячу раз об этом передумано..
Объект должен сам руководить своими внутреннеми процессами, а не полагаться на внешнее управление. 
Открытые переменные говорят об незакончености объекта.  Кастати объект состояших из Гетеров и Сеттеров тоже плох. 
В таком случае он объект, а блок данных.  Даже просто поняв разницу между двумя последними понятиями , можно почуствовать проблему открытых членов.
А сводится все к тому что, если реализация класса выполнена приватно, то все связи находятся в одной локальной области и легки для проверки и контроля.
Если объект предоствляет открытый доступ к реализации, то она расползается по всему коду программы и любая модификация исходника с каждым таким шагом сильно затрудняется... И не только модификация, но и просто понимание проги.
ООП чем и хорош что предполагает что каждый объект можно протестировать(и понять) без участия остальных.
Естественно , чем меньше  связей тем легче .. 

Ну ок. Делай несколько базовых классов(рыба, дерево), которые хранят static-флаг visible. 

виртуальная ф-я  IsVisible

Нет.. глядеть надо не стороны лекций, а со сторны инструментария предоставляемго языком.. ООП помогает писать так, чтоб это было красиво, понятно и при этом без ушерба в скорости...
Например казалось бы что программа написанная в машиных кодах будет работаь быстрей, чем такая же прога на Си,
однако зачастую наблюдается обратная ситуация.. Потому что чтоб выйграть в скорости при писании в маешинах кодах, надо знать архитектура компа  и сопотимизировать под нее свою лучше, чем это сделает компилятор..(а сравниться с компиляторами, особенно заточенными под нужную платформу, смогут лишь единицы). То же происходит если сравнить С и Сpp.. При компиляции весь ооп разворачивается и в результате имеем тот же си код . Зато при составлении, инструментарий ООП позволяет значительно снизить нагрузку с программиста, если он правильно его использует.
То есть имеем те же пряники, но за меньшее время и с меньшей головной болью..

Добавлено через 2 минуты и 41 секунду


нельзя ли объяснить что именно Вы хотите..
потому как например в этой строчке

найти смысл очень сложно ... 

...

Это сообщение отредактировал(а) mes - 28.8.2008, 16:46

Вот о скорости... Пример последний - это вызов функции isVisible. Будет ли эффективно, если мне нужно обработать 1 млн объектов, в цикле вызывать эту функцию? Может конечно сделать inline, но вот интересно к какому виду это приведет интерпретатор (как кто-то тут говорил "С++ код все равно приводится к Си")...

да, будет, так как все это дело соптимизируется


хотя тут особо оптимизироваться нечему... возврат значения...

Добавлено через 2 минуты
кстати, почему бы тебе самому не попробовать сравнить?

Это сообщение отредактировал(а) Alek86 - 28.8.2008, 16:55

Сравнивал... Обычный цикл работает на 10% медленнее с этим isVisible что с inline что без. А вот взятие значения из памяти быстрее...

И как ты сравнивал?

Вот код... Если get(i) заменить на a[i], то работает за 3 секунды. А в приведенном варианте 63 секунды. Это если голый пример (у меня разница на 10%, а тут раз в 20).

Если выставить сборку Release в студии и установить Optimization: Maximize Speed (/O2), то оба варианта имеют одинаковое время исполнения.

Посмотрел ассемблерный листинг. В обоих случаях выходит один и тот же машинный код. 

Это сообщение отредактировал(а) W4FhLF - 28.8.2008, 17:42

с включенной оптимизацией результат в обоих случаях 2578 тиков
5719 с прямым доступом  и 9063 через get()

итог > разрешите компилятору соптимизировать вместо того чтоб мучиться самому   

Ну не все же пишут в виндовсе...

Anton Vatchenko, ну твой то код определённо под винду  И это не от оперционки зависит, а от компилятора и умения его настроить. Если есть желание писать вместо кода кашу и делать monkeyjob за компилятор, то это личное дело каждого. Просто это глупо  

За что люблю Сишников, вооружатся стандартом  и умными книжками и с рвением святой инквизиции доказывают всем мнение чужого дядьки   
public перменные маст хэв, не надо от них чуратся как от прокаженных. Если надо, значит юзай.
Кстати очень интересная позиция замены паблик переменных сетами и гетами, если есть сеты и геты для переменной то это уже нарушение инкапсуляции, так что тут не важно как это выглядит, через методы, либо напрямую. Все одно. Правда напрямую меньше букофф, так что выбирать надо то, что удобно, а не то, что дядьки чужие насоветовали  В конце концов программирование это искусство, а не писание по шаблонам.

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


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

Хм... Где здесь нарушение? Разве взаимодействие с интерфейсом считается нарушением инкапсуляции? 

ты открыл доступ к внутреннему состоянию, интерфейс\напрямую не важно, важно то, что пользователь получает доступ. А это нарушение.

то пусть почитает еще книжек, потому как  инкапсуляция - часть фундамнтальной основы ООП.



Нужно понимать, что приватная переменная + методы доступа к ней = паблик переменная, за исключением случая, когда в set() например нужно организовать проверку значения ну или какие-либо дополнительные манипуляции

vinter, так весь смысл в том, что доступ через интерфейс контролируемый при любой операции, связанной с внутренним состоянием объекта. Это не нарушение(если не впадать в абсолютизм). 

Геттеры/сеттеры инкапсулируют внутреннюю структуру объекта и позволяют осуществить контроль доступа, т.е. инкапсулируют правила по которым доступ должен быть осуществлён(проверка границ, типа, размеров etc.)

Это сообщение отредактировал(а) W4FhLF - 29.8.2008, 09:42

с этой частью я согласен. Ты видимо меня не понял, я говорил о внутренней перменной, для которой есть гет\сет просто как return\=, т.е это то же самое, что паблик, но типо скрыто за интерфейс. Я говорил об этом.

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

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


кроме "мнения чужого дядьки" есть еще собственный опыт мучения при рефакторинге кода, отладке, обнаружении багов...

а я говорю нарушают, и кто прав?


и что? паблик переменная точно так же пропадет, разница в чем?

Т.е.? Что такое по-твоему внутреннее состояние? Ну допстим свойство visible объекта характеризует его внутреннее состояние. Почему геты и сеты здесь должны отсутсововать?




Ты ещё сказал, что паблик переменные маст хэв когда они нужны. А когда они нужны-то? 

Кроме случаев с простейшими структурами-классами типа:



Ничего придумать не могу.

Подождите, кто сказал что мой код под винду? Он под линуксом работает, вот только хочу узнать как сделать, чтобы работал правильно...

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

к примеру есть класс Квадрат

ты, конечно же, сделаешь просто структуру


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

что сделаешь ты?

Это сообщение отредактировал(а) Alek86 - 29.8.2008, 10:38

Anton Vatchenko, тестовый пример, на котором ты измерял скорость, под винду. А как сделать правильно тебе уже показали. 

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

не могу сходу пример привести, просто я не отметаю их использование совсем, т.е если надо, значит надо.
Глупый конечно пример, НО Синглтон.

разницы нет, в Винде С++ ничем не отличается 

Добавлено через 3 минуты и 41 секунду
Alek86, я сделаю через КЭШ, Get для площади кеширует вычисление, т.е не вычисляет, если уже вычислен. Хотя конкретно в данном примере это роли не играет.
Set это Set, почему в Set происходит вычисление сторонней переменной? это не гут.

обычно его реализуют с помощью статичесткой ф-ии GetInstance()...


кстати, как во всяком правиле, тут (неиспользование паблик переменных) есть исключения
и в приведенной задаче в книге Саттера они описываются.
и их процент очень мал (думаю, меньше одного)

я имел ввиду данные которые Синглтон хранит, а не экземпляр

set - это set для юзера
а прогер может писать там все, что посчитает нужным для ускорения или упрощения вида класса
там может со временем вообще 10 переменных меняться (если того потребуют обстоятельства).
в этом и заключается вся прелесть инкапсуляции + отделения интерфейса от реализации класса


можно в коде? вроде его не так уж и много

Добавлено через 1 минуту и 18 секунд

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

Singleton можно использовать как глобальное хранилище параметров, вот там много паблик переменных.

согласен, но толлько если там простейшие операции, если идут математические вычисление, то это не гут. Пользователь делает Set, он не просит вычилить площадь, она ему может никогда не понадобиться.

vinter, а теперь посморти на свой код и мой

если программист А использует мой код, а программист Б - твой, то у какого программиста будет меньше всего проблем при изменении класса Square (или структуры на класс)?

Добавлено через 36 секунд
придирка
bool m_bSurCache; должен быть mutable

нарушает ?


Это сообщение отредактировал(а) mes - 29.8.2008, 11:31

я привел пример, когда стороны квадратов меняются редко а площади требуются часто

  

проблема изменения не показатель эффективности, представь что вместо вычисления площади идет вычисления обратной матрицы через LUP разложение, ты это тоже во все change методы запихнешь? Все зависит от конкретной задачи, мне ближе cache идеология. 
К тому же я не вижу, проблем в изменении моего класса.

структуры (не по слову struct , a по смыслу) - это блок данных , который не имеет  внутреннего состояния , а только внешнее..
В таких случаях инкапсулировать просто нечего 

нет, а вот  меняем название класса на

и получаем нарушение инкапсуляции.

Показатель !

"Проблема изменения" не фактическое выражение , а условное.. Совсем не обязательно "надеяться", что класс будет когда то изменен.
Оно говорит   о том  насколько клиент посвяшен в дела сервера и этим показывает связь реализации.
Чем меньше связь , тем больше сил и памяти остается у программиста на остальные проблемы .

Добавлено через 5 минут и 22 секунды

Поэтому и надо понимать какую сущность Вы реализуете.. и от этого зависит применение инструментария.
Геттер в чистом виде это не функция Get..() , а функция возврашая не  внутренне состояние, а одну из его составляюших реализации этого состояния. (что и вынуждает повышеное знание об устройстве на стороне клиента )

Добавлено через 13 минут и 7 секунд

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

class A
{
int Get_someElment() {return someElment; }
private:
int someElment;
.
.
.
};

class B
{

public:
int someElement;
.
.
.
};

someFunction()
{
A objA;
B objB;

objB.someElement =10;

memcpy((void*)&objB, (void*)&someElement,sizeof(objB));
}


Результат такой каманды:
objA.Get_someElment();


Так что приватные члены делать не особого смысла

не совсем понял чего Вы добивались показать своим примером? 

То что можно применить хак и добыть данные из объекта, которые являются приватными?
Да можно.
Только Вы забываетесь , если думаете что ограничение доступа , призвано уберечь данные от повреждения
средствами хака. Хак на то и хак - компилятор умывает руки и вся ответственность перекладывается на программиста.

Этот инструментарий  (ограничение доступа ) призван "всего лишь" облегчить жизнь программиста, указывая на ошибки использования,
ориентируясь на описание класса которое дал сам программист. 
То есть:
Чем правильнее выявит интерфейс, тем легче ему будет использовать его в дальнейшем. 
Чем лучше будет изолирована реализация, тем меньше придется программисту задумываться о том как подключить данную сущность к общему коду. 
Чем меньше будет внешних связей, тем легче выявить и локализировать ошибку/баг.
И многое другое..

Программистам которые  уверенны, что их память предназначена для того, чтоб  держать в голове номер смещения и размер переменной,
перечисленные выше средства компилятора абсолютно не нужны.. Мне только не понятно зачем они выбрали С++, когда на ассемблере 
или хотя бы си простор для самостоятельного контроля без помощи компилятора гораздо шире.



Это сообщение отредактировал(а) mes - 4.9.2008, 21:59