Потрібно використати дружню функцію, щоб додати дві сторони в класі, компілятор вибиває постійно помилки, або ієрогліфи

Ні. Дружні функції доповнюють інкапсуляцію. В C++ це спосіб надати функції доступ до приватних членів.
Іноді неможливо невикористовувати дружні функції.

Для початку перевірте свій код на синтактичні помилки:

return  obj1.width + obj2,lenght ;

А потім вже наведіть помилки компілера (якщо вони взагалі будуть).

Щось я не можу зрозуміти вашої логіки.
То по вашому [ get- | set- ] методи, які [ повертають | встановлюють ] значення приватних полів - це теж порушення інкапсуляції ?

Або можливо ви забули як функції робляться дружніми ? То я нагадаю :

#include <iostream>
using namespace std;

class SomeClass;

// Оголошення функції "println".
void println(SomeClass &, ostream &);

class SomeClass
{
    private:
        int _value;

    // Робимо функцію "println" дружньою для класу "SomeClass".
    friend void println(SomeClass &, ostream &);
};

// Реалізуємо функцію "println"
void println(SomeClass &obj, ostream &out)
{
    out << "Value : " << obj._value << endl;
    // Вивести приватне поле можна тільки коли
    // "SomeClass" містить оголошення, що
    // ця функція дружня для класу "SomeClass".
}

int main(int argc, char **argv)
{
    SomeClass obj;
    println(obj, cout);
    return 0;
}

На цьому прикладі видно, що для того, щоб зробити функцію println дружньою, автор класу SomeClass повинен явно це прописати (стрічка коду: 15). Без цього зовнішня функція не отримає доступ до приватних полів. Ну і де тут порушення інкапсуляції ? Поясніть мені.

Інкапсуляцією я вважаю приховування приватних знань від якомога більшої кількості користувачів цих знань. Чим більше користувачів має доступ до цих знань тим більше порушена інкапсуляція. Тобто додавання дружньої функції до класу розширює список тих хто має доступ до приватних даних, а отже зменшує інкапсуляцію даних. Роботу з приватними даними інкапсулюють виставляючи назовні інтерфейс і цей інтерфейс спроектований і реалізований так щоб підтримувати інваріант даних. Тому я як користувач цього інтерфейсу розраховую на те що дані завжди знаходяться в інваріанті.

Схематичний приклад. Клас має свій узгоджений внутрішній стан до тих пір доки не буде використана дружня функція, яка може призвести до порушення інваріанту класа.

class Odd
{
public:
    void setA(int a) { a_ = a; isOdd_ = a_ % 2; }
    bool isOdd() const { return isOdd_; }
    friend void mess(Odd & t);
private:
    int a_;
    bool isOdd_;
};

void mess(Odd & t)
{
    t.a_ = 5;
}

В таких випадках користувачу класа потрібно не тільки розбиратись як користуватись інтерфейсом, але й ретельно досліджувати що робить дружня функція, оскільки впливає або може вплинути на внутрішній стан класу в обхід його інтерфейса. Фактично, функція вже є частиною інтерфейсу класа.
І я вважаю це порушенням інкапсуляції.

Ок. Тут норм.

Допустимо.

Ясне діло.

Тут маю зауваження. Якщо автор класу (в даному випадку "Odd") робить функцію ("mess") дружньою, то автор цієї функції зобов'язаний зробити так, щоб внутрішній стан класу (або екземпляра) не був порушений на момент завершення роботи цієї функції.

Ясно, що ніхто не робить функцію дружньою, коли в цьому немає необхідності. Просто мені бомбануло від фрази: "дружні функції порушують інкапсуляцію".

Не потрібно. Тут якраз автори класу і дружніх функцій повинні подбати про те, щоб внутрішній стан класу не став сюрпризом для користувача.

Так.

А я так не вважаю.

А хто заважає фабриці бути static public?