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


Это сообщение отредактировал(а) 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 секунду


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

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