Обекты, или как испортить калькулятор

[Nerazumovskiy]

Ну дело предстоит так.
Задали нам написать калькулятор, но зарание предупредили что будут усложнения. Преподаватель быстренько написал нам РБНФ и сказал "Думайте". Я прикинул что неплохо было-бы поучится обектно ориентированому програмириванию, темболие я какраз недавно читал о класах. На этом и порешыл, попрактикуюсь в обектном-ориентированом програмирывании. Сразуже написал класс отвечающий за ввод, реализовал несколько методов, написал маленькую тест программу. Прихожу показываю, в ответ получаю много критики в свою сторону. С репликами : "Это не обекто ориентированая програма, и зачем ты заставляеш ее работать последовательно обекты должны общатся между собой, и ты не должен делать это извне..." Еду домой и думаю а как их заставить общатся, если чтобы обект существовал его надо обявить хотябы. Получается я обявляю Обект1 обявляаю Обект2 и только потом могу чтото с ними делать, но это както несостыкуется с идеей общения. Ведь чтобы общатся надо знать с кем, тоесть надо внутри Обекта1 обявить Обект2 и потом чтото с ним делать, итд.
Вопрос заключается в следующем:
Как всетаки это делается правильно.

Вот кусок кода

#include <cstdlib>
#include <iostream>
#include <string>

#define MAXINT 32767

class BuffIO
 {
 public:

     bool NewS();
     string PutS(){ return S;}
     BuffIO(){i=0;}
     bool SetS(string);
     string NextLex();               
     

 private:
          int i;
          string S; 
 };

bool BuffIO::NewS()
     {      
          char temp = 0;  
      
          int k=0;

          for(; temp!='\n' && k<= MAXINT-1 ;)
           { 
             temp=getchar();

             S[k++] = temp;
            }
           S[k] = '\0' ;           
           
              return 0;                    
      }
       
        
string BuffIO::NextLex()
{
      string t;

      int k=0;

       for( ;(S[i]!= ' ')||(S[i]!= '\t'); i++)
         {
               t[k++]= S[i];                         
         }
          cout<< t;
            

       return t;
}

 int main()

 {

      BuffIO test;
     
      test.NewS();   
      
      string t = test.PutS();
      
      std::cout<<t;
         
      string a; 
            
      a = test.NextLex();
      
      std::cout<<a; 
      
      system("pause");
      return 0;
}

[e2e4]

1. Целевое использование Вашего класса, отвечающий за ввод, мягко говоря, не очевидно.
2. Функция BuffIO::NextLex(), даже при моем недоумении, что она должна делать, содержит несколько явных ошибок.
3. На основании одного приведенного Вами класса невозможно судить о наличии/отсутствии, а также о характере взаимодействия остальных классов программы "калькулятор". Поэтому критика в Ваш адрес пока необоснованна - критиковать по сути нечего, т.к. ничего по сути не написано.
4. Для того, чтобы судить о структуре Вашей программы, приведите описание и взаимодейтсвие всех предполагаемых классов программы, причем, я настаиваю, на русском языке, а не на языке Си++. Можно в виде графа, диаграммы и т.п. А там посмотрим.

Добавлено спустя 2 минуты 21 секунду:

Вместо #define MAXINT 32767 рекомендуется использовать #include "limits.h", или аналогичный файл из поставки компилятора, где определяется именованная константа MAXINT.

[Nerazumovskiy]

Ну я так понял что преподаватель решыл убить мое неправильное понимание обектно-ориентирываного програмирывания ещо в зародыше.
А схема которую я хоче реализовать достаточно проста:
--Долны быть 4 блока:
1) Отдельный модуль для ввода-вывода(в котором должен быть метод обработки строк, который дает возможность розбить ввод на слова)
2)Модуль анализатора слов( должен уметь отличить между собой :
-команду
-коментарий
-собственно выражение которое надо посчитать
-мусор )
3)Блок обработки команд
4)Блок вычисления выражений
--Взаимодейтсовать они должны просто. Блок схему рисовать небуду, так как связи тут очевидны. Ввод-->Анализ текста--> Обработка команд-->Формирование выражения которое надо пощитать-> Вычисление-->Выводрезультата-->Запрос команды-->Ввод

Ну это не окончательная схема, потом на основании этого буду уже добавлять чтото походу.

Добавлено спустя 2 минуты 13 секунд:

Я ещо раз повторю вопрос, как зделать так чтобы эта последовательносто шла автоматически, без принудительного вызова мной из main-а методов этих класов.

[e2e4]

Цитата:

Я ещо раз повторю вопрос, как зделать так чтобы эта последовательносто шла автоматически, без принудительного вызова мной из main-а методов этих класов.

Это самоцель?
Создавайте локальную переменную в main() типа Вашего класса, в конструкторе класса делайте всю работу программы (Ваш класс должен включать все остальные Ваши классы либо как члены, либо как классы-предки). Еще суровее: глобальная переменная типа Вашего класса. Тогла main() вообще можно оставить пустой.

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

Предложенную Вами структуру программы прочитаю и осмыслю завтра, может быть кто-то раньше выскажет свои пожелания.

[Nerazumovskiy]

Это не самоцель, сомоцель понять обектно ориентированое програмирование.

[zbl]

Nerazumovskiy писал(а):

Это не самоцель, сомоцель понять обектно ориентированое програмирование.

На данном примере трудно будет понять: задачи синтаксического анализа лучше ложатся на функциональную парадигму, чем в ООП.
У Вас тут явный поток/фильтр данных; алгоритмическая декомпозиция будет не менее (если не более) удобной, чем объектная.
Хотя, конечно, можно...
Типа построить калькулятор по схеме классной доски, которую используют, например, в дешифровании и добыче данных.
Но не слишком ли мудро это будет?

[Pavia]

zbl

Цитата:

На данном примере трудно будет понять: задачи синтаксического анализа лучше ложатся на функциональную парадигму, чем в ООП.

Несогласен. На ООП это какраз таки ложиться хорошо. Но суть ООП доконца не раскрывает.

Nerazumovskiy

Цитата:

Я ещо раз повторю вопрос, как зделать так чтобы эта последовательносто шла автоматически, без принудительного вызова мной из main-а методов этих класов.

тебе ответили на этот вопрос.
Методы одного класса должны вызывать методы другого. Для этого нужна ссылка на экземпляр нужного класса.

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

Цитата:

Взаимодейтсовать они должны просто. Блок схему рисовать небуду, так как связи тут очевидны. Ввод-->Анализ текста--> Обработка команд-->Формирование выражения которое надо пощитать-> Вычисление-->Выводрезультата-->Запрос команды-->Ввод

Неплохобы и обратные связи реализовать. И хорошенько продумать кто кого должен вызывать.

[Nerazumovskiy]

Pavia писал(а):

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

Вот та цепочка которая у меня это то что надо?

[zbl]

Pavia писал(а):

На ООП это какраз таки ложиться хорошо. Но суть ООП доконца не раскрывает.

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

Добавлено спустя 16 минут 29 секунд:

Nerazumovskiy писал(а):

Вот та цепочка которая у меня это то что надо?

Уже говорилось, что то, что приведено выше -- это ничего не приведено.
Поэтому и ответ отрицательный.

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

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