Доступ к методам (функциям) класса., Выбор оптимального способа Опции

[Stas633]

Допустим:
- имеются два класса TOne и TTwo;
- в TOne определена ф-ция FuncOne();
- классы определены в разных единицах компиляции (файлах);
- созданы объекты (глобальные) этих классов (mOne и mTwo) в третьем файле - "main.cpp".
Вопрос:
Как из класса TTwo получить доступ (использовать) функцию FuncOne() класса TOne?

1. наследовать TOne в TTwo
2. перед описанием класса TTwo объявить объект классаа TOne: extern TOne mOne.
3. ...?
...
А если таких "вложений" больше? (Т.е. функции TTwo, использующие TOne, необходимы в TThree)

Что лучше? Как правильнее? Есть ли разница в испозовании стека?

Прим. Например: TOne - класс описывающий работу с индикатором (LCD), а TTwo - класс формирования данных для вывода на индикатор. Рассматривается ситуация одного процесса (не RTOS).

Прим.1 Вопрос задаю здесь, так как обсуждение темы о выделении раздела форума для "чистого" программирования, увы, ни к чему не привело. Господа Админы/Модераторы извините, просмотрел..

[dxp]

Что лучше? Как правильнее? Есть ли разница в испозовании стека?

Прим. Например: TOne - класс описывающий работу с индикатором (LCD), а TTwo - класс формирования данных для вывода на индикатор. Рассматривается ситуация одного процесса (не RTOS).

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

[Stas633]

Ув. dxp, спасибо за Ваши советы/рекомендации (в другой ветке)!!!
... При внешней схожести С и С++ очень разные языки... ...разные тем, что на них думать надо совсем по-разному... ...
Попробуйте думать над программой на уровне объектов реального мира, ..., тогда реализация ляжет на классы почти сама собой... (с) dxp

Начал ознакомление с работами Страуструпа и Буча ("настольной книгой", до последнего времени, был "Самоучитель..." Шилдта) и сразу понял, что, используя синтаксис и правила С++, пишу на Си! Отсюда и "проблемы" вида: ".. как сделать функцию доступной.." и т.д.
При написании программы я использовал "прямое" наследование для получения доступа к функциям базовых классов. Т.е. при создании объекта производного класса создавался объект/копия базового класса и таких копий было "множество", хотя достаточно одной единственной. Последствия, в виде "нехватки" ОЗУ, очевидны... Отсюда и мой интерес к получению "беззатратного" доступа к "чужим" функциям.
Программу нужно писать на С++, а не на Си, изпользуя С++ синтатсис и правила!! Т.е. начинать нужно с рисования структуры связей и т.д.
Спасибо еще раз!

... Если классы живут сами по себе, то ничего вышесказанного делать не нужно, а общение меж ними организовать на открытой части (public)....

Что Вы имеете ввиду? Если не через наследование, то как тогда?

[dxp]

Что Вы имеете ввиду? Если не через наследование, то как тогда?

Не очень понимаю затруднение. Вот имеем код:

Код

class TSlon
{
public:
    TSlon();
    void f();
};

class TMamont
{
public:
    TMamont();
    void f();
};
...

TSlon slon;
TMamont mamont;

void TMamont::f()
{
    slon.f();
}

как видно, спокойно вызываем из функции одного класса функцию другого. Все public члены классов доступны внешнему окружению без каких-либо ограничений. Это так задумано, и это логично. Управление доступом - основа инкапсуляции/абстракции. Представление прячем в private секцию объекта, а общение (функциональность) делаем через интерфейс - public секцию. Как правило, в public секции присутствуют только функции. Т.е. интерфейс - это действия, которые может выполнять объект, а доступ к данным снаружи как правило не нужен и чреват хаками и ошибками. Хотя, конечно, язык не запрещает делать открытыми и данные-члены.

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

Или вам что-то другое надо?

[Stas633]

Или вам что-то другое надо?

Нет, "другого" не нужно. Вопрос в разной терминологии. Вы это называете "...общение ... на открытой части...", а я называл "..объявлением объекта перед использованием класса". Ваша терминология конечно правиль-на (-нee). Вообще, "одинаковый алфавит" - это начало начал при обсуждении любого вопроса.
В предложенном варианте необходимо "помнить" (держать в памяти) где и с каким именем объявлен объект slon. Если он объявлен в main - файле, то в в файле описания TMamont нужно этот обект объявлять как extern и т.д. Т.е. опять "возврат" к Си.

По "точный" ответ на "точный" вопрос вспомнился старый анекдот... Когда воздухоплаватель на воздушном шаре приземлился в незнакомой местности и спросил у проходившего мимо программиста: "Где я нахожусь?". И тот, после недолгого раздумья, ответил: "Вы находитесь в корзине воздушного шара." Ответ правильный и точный но...
(не примите, плз., это на свой счет, это так, к слову).
...
Правильнее, на мой "просветленный" взгляд, построить "объектную модель программы" и создать иерархию классов с использованием абстактных классов (гл.12, "Язык программирования C++", Б.Страуструп). Хотя для Си - программиста это и покажется более сложным. Кстати, предложенную Вами реализацию меню через наследование абстактного класса успешно реализовал, правда, как оказалось, не понимая сути

Тут надо смотреть, как правильнее по смыслу.
...
Хорошо об этих проблемах написано в книге ""Философия Java".

Вы правы - "Философия...". Т.е. нужно менять подход, а не искать "средства".
В общем-то, вопрос о способах доступа раскрыт, как мне кажется, полностью.
Главный вывод это то, что нельзя (неправильно, трудно, неэффективно...) использовать объекты для описания процедур.
Нужно или "заниматься" (программировать) обектно ориентированным программированием, или процедурным. Написана программа на Си - нет смысла пытаться "подогнать" ее под С++. А вот использовать готовые куски кода (функции) - пожалуйста.
Спасибо!

P.S. Способов два:
- через наследование. НО! Если базовые классы не являются абстрактными, но наследование приводит к избыточному наличию копий базовых классов (обектов) (если не прав - поправьте);
- через указатель на класс (объект). НО! Здесь проявляется вся "прелесть" продердурного программирования и смысл перехода от Си к С++ теряется.
... предложенное dxp "включить один (класс) в другой" не рассматриваю, так как производных классов несколько, и включение базового в каждый .............

Вместе с тем, любой из вариантов работоспособен и не является ошибочным. И, в зависимости от ситуации, может быть применен.

[dxp]

В предложенном варианте необходимо "помнить" (держать в памяти) где и с каким именем объявлен объект slon. Если он объявлен в main - файле, то в в файле описания TMamont нужно этот обект объявлять как extern и т.д. Т.е. опять "возврат" к Си.

Никакого возврата нет, т.к. С++ - это надмножество С, и использует те же средства в полном объеме. Помнить, под каким именем объявлен объект slon не надо - он объявлен под именем slon. Для организации доступа к глобальному объекту нужно (в данном случае):

1. Определения классов поместить в заголовочный файл, который включается во все исходные файлы проекта.
2. В одном из исходных файлов объявить сами объекты.
3. В вышеуказанном заголовочном файле поместить следующие объявления:
   extern TSlon slon;
   extern TMamon mamont;

Все, теперь оба объекта будут доступны везде. Если надо доступ к потрохам, об этом уже сказано выше.

Никто почему-то не сказал о средстве friend.
Т. е. в классе TTwo обьявить другом класс TOne.

Почему не сказал? Было предложено.

А чем наследование лучше/хуже доступа через friend? (для рассматриваемого случая)

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

Далее. Допустим есть объекты "слон", "мамонт" и "стадо". Поскольку стадо состоит из животных, то логично, чтобы объект "стадо" включал в себя объекты слонов и мамонтов (возможно, в виде массивов). Это отношение включения.

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

Словом, вам надо определиться, какие у вас отношния между объектами, и строить код уже исходя из этого. А на ощупь и методом тыка ничего хорошего не получится.

[?ELF]

...
...
...

Словом, вам надо определиться, какие у вас отношния между объектами, и строить код уже исходя из этого. А на ощупь и методом тыка ничего хорошего не получится.

Спасибо!
Хорошая аллегория.
Прочитал Ваш ответ -- словно "в юности побывал" -- "Страуструпп Б. - Язык программирования С++., Диасофт, Киев, 1993."

---
Вообще, такие вещи, на мой взгляд, более логично и более глубоко описывались в Prolog-е.
Создал "базу знаний" -- и вперёд!
Используй термы, предложения, правила, предикаты...
Почти умер язык, к сожалению.
Не выдержал коммерческого натиска C++.