Prywatne funkcje w C++ - kilka pytań

Witam, dopiero zaczynam naukę programowania w C++ i mam kilka pytań do tego kodu:

#include <iostream>

using namespace std;

class Funkcje{
//public:
    int silnia(int n){
        if(n==0) return 1;
        else if(n==1) return 1;
        else return n*silnia(n-1);
    }
};

class Liczby{
public:
    int x;
    int y;


    Liczby(){
        x=5;
        y=9;
    }
};

int main(){
    Funkcje a;
    Liczby o1;
    cout << a.silnia(o1.y-o1.x) << endl;
    cout << o1.x;
return 0;
}

1. Co należy dopisać tak, aby po prostu program działał? Chodzi mi o coś innego niż odkomentowanie "public" w klasie Funkcje. Czytałem o zaprzyjaźnianiu i dziedziczeniu, ale nic mi tu nie wychodzi.
2. Gdybyśmy w klasie liczby zmienili int x i int y na private to nie działałaby linijka cout << o1.x; co można wtedy zrobić?
3. Czy można wywołać polecenie a.silnia(o1.y-o1.x) nie tworząc obiektu a klasy Funkcje, tylko po prostu korzystać z zawartości klasy Funkcje?

Wiem, że pewnie są to rzeczy, które da się zrobić lepiej, ale na razie się uczę i interesują mnie takie szczegóły, więc byłbym wdzięczny gdyby ktoś mi pokazał jak to ma wyglądać. Z góry dziękuję :)

ressponse napisał(a):

1. Co należy dopisać tak, aby po prostu program działał? Chodzi mi o coś innego niż odkomentowanie "public" w klasie Funkcje. Czytałem o zaprzyjaźnianiu i dziedziczeniu, ale nic mi tu nie wychodzi.
2. Gdybyśmy w klasie liczby zmienili int x i int y na private to nie działałaby linijka cout << o1.x; co można wtedy zrobić?
3. Czy można wywołać polecenie a.silnia(o1.y-o1.x) nie tworząc obiektu a klasy Funkcje, tylko po prostu korzystać z zawartości klasy Funkcje?

1. ale właściwie co Ci nie pasuje w zostawieniu tego pod public?
2. można dopisać metody które będą publiczne i będą zwracać zawartość tych zmiennych. Tak zwany interfejs klasy. Ewentualnie mechanizm zaprzyjaźniania, gdzie deklarujesz w klasie funkcje spoza tej klasy, które mogą mieć dostęp do jej prywatnych zmiennych.
3. Można, robiąc metodę statyczną. (słowo kluczowe static) Nie będzie to jednak standardowe ani wskazane zastosowanie dla static - w Twoim programie funkcja licząca silnie jest na siłę wciśnięta do klasy, a może być przecież "wolną" funkcją poza jakąkolwiek klasą (nie wszystko w c++ musi być częścią klasy)

Ad1. Ja osobiście nie lubię mieć zmiennych dostępnych z zewnątrz. Wtedy może mi je każdy dowolnie zmieniać, a to nie jest takie fajne, zwłaszcza w większych projektach. Czasem trzeba odpowiednio reagować na zmianę wartości zmiennej.

Ad2. Interfejs to troszkę co innego. To co opisujesz to są po prostu gettery/settery. Bardzo pożyteczny mechanizm. Zaprzyjaźnianie moim zdaniem powoduje zbyt wielkie zależności i staram się go unikać.

AD3. Fakt, ale zawsze można zrobić klasę typu helper gdzie składowe jak najbardziej będą staticami.

A czy mógłby ktoś po prostu pokazać jak wyglądałby kod po poprawkach? Ja słyszałem, że tutaj jest zakaz próśb o gotowce, ale jednak często patrząc na kod jest mi dużo łatwiej coś zrozumieć.

@ressponse tak przyjrzałem się bardziej i jak dla mnie to pewne rzeczy masz bez sensu. Class Liczby jest zupełnie zbędne, a zrobione na zasadzie sztuka dla sztuki. Ale pokaże Ci jak to zrobić. Co do funkcji silnia, to jej nazwa mało mówi, a samą funkcję zrobiłem jako static. Jest na tyle prosta, że idealnie pasuje na metodę statyczną.

#include <iostream>

using namespace std;

class Silnia
{
public:
  Silnia(void) {};
  ~Silnia(void) {};

  static int ObliczSilnia(int n);
};

int Silnia::ObliczSilnia(int n)
{
  if(n==0)
    return 1;
  else if(n==1)
    return 1;
  else return
    n*ObliczSilnia(n-1);
}

class Liczby
{
private:
  int x;
  int y;
public:
  Liczby();
  int DajX();
  int DajY();
};

Liczby::Liczby()
{
  x=5;
  y=9;
}

Liczby::DajX()
{
  return x;
}

Liczby::DajY()
{
  return y;
}

int main()
{
  Liczby o1;
  cout << Silnia::ObliczSilnia(o1.DajY()-o1.DajY()) << endl;
  cout << o1.DajX();

  return 0;
}

Jako ćwiczenie pozostawiam napisanie metody ustawiającej wartość x oraz y. No i polecałbym Ci nazywanie zmiennych, metod po angielsku. Już getter nazywający się Dajxxx żle wygląda, a pomyśl jak będzie się nazywał setter Ustawxxx? Natomiast same funkcje nazywaj tak żeby bardziej mówiły do czego służą.