[РЕШЕНО] Переопределения метода, использующего приватные переменные

[unkeep]

Есть базовый класс, в котором метод что-то делает используя при этом закрытые переменные класса. Я наследуюсь от базового класса и пытаюсь переопределить этот метод, но доступ к переменным я получить не могу.
Поможет ли если в базовом классе сделать переменные не private a protected?
Есть ли другие способы изменить реализацию метода не влезая в базовый класс?

[Bepec]

Кхм. Могу врать, но если вы наследуетесь, то у вас уже есть доступ к приватным полям класса вроде.

А метод виртуальный?

[unkeep]

Кхм. Могу врать, но если вы наследуетесь, то у вас уже есть доступ к приватным полям класса вроде.

А метод виртуальный?

метод вируальный. а при наследовании приватные(private) переменные видны но не доступны.

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

пока у меня есть три варианта:
1)унаследоваться и пререопределить нужные методы (самый правильный, но, боюсь, невозможный)
2)внести изменения в базовый класс. (не желательно)
3) создать новый класс, скопировав код из базового и в новом уже реализовать так как надо (как-то не рационально)

[Пантер]

А нужен интерфейс базового класса? Можно же через агрегацию. Вообще, нужно больше конкретики, чтобы найти лучшее решение.

[lit-uriy]

можно немного подправить базовый класс. Сделать дополнительные зищищённые методы, возвращающие ссылки на личные (private более естественно переводить именно так, вместо общепринятого "закрытые") переменные.

[unkeep]

можно немного подправить базовый класс. Сделать дополнительные зищищённые методы, возвращающие ссылки на личные (private более естественно переводить именно так, вместо общепринятого "закрытые") переменные.

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

[xokc]

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

Какие тонкие формулировки

[Igors]

Ну а чем плохо сделать нужные члены protected? Или вообще не морочить голову и объявить все public? Да, это единодушно осуждается, но в жизни часто непросто доказать что private (вкупе с геттерами/сеттерами) чего-то стоит. Обычно это "песики" которые наводят так, "на всякий случай" - не более того 

[Пантер]

Ну а чем плохо сделать нужные члены protected? Или вообще не морочить голову и объявить все public? Да, это единодушно осуждается, но в жизни часто непросто доказать что private (вкупе с геттерами/сеттерами) чего-то стоит. Обычно это "песики" которые наводят так, "на всякий случай" - не более того 

Тем, что кто-то может так полезть куда ему не следует и испортить что-нибудь. Да и единый стиль стоит все таки соблюдать.

[Alexu007]

Тем, что кто-то может так полезть куда ему не следует и испортить что-нибудь. Да и единый стиль стоит все таки соблюдать.

Эт если скомпилированная библиотека, а если opensource - там любой может залезть куда ему не следует и сломать что захочет. Или я чего-то не то сморозил?

[Bepec]

Сморозил наверно

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

[Igors]

Эт если скомпилированная библиотека, а если opensource - там любой может залезть куда ему не следует и сломать что захочет.

Может, но (по-хорошему) private прозрачно намекает что можно получить по ушам если менять этот член "просто так". Изменяющий "в курсе" и открывает private только если никаких др ходов не нашлось

[Пантер]

Тем, что кто-то может так полезть куда ему не следует и испортить что-нибудь. Да и единый стиль стоит все таки соблюдать.

Эт если скомпилированная библиотека, а если opensource - там любой может залезть куда ему не следует и сломать что захочет. Или я чего-то не то сморозил?

Все можно поломать. Я имел ввиду, что по неосторожности не сломаешь ничего, если интерфейс не дает лишнего доступа.