Dziedziczenie publiczne czy zawieranie?

Question

Załóżmy, że Napisałeś aplikację, która jest dostępna w dwóch językach: polskim i angielskim. Język w Twojej aplikacji ustawiany jest na podstawie języka w systemie operacyjnym. Jeżeli system operacyjny korzysta z języka polskiego, to podczas startu aplikacji ładujesz tłumaczenie na polski, w przeciwnym wypadku ładujesz angielski.

Przykład kodu nieobiektowego z wykorzystaniem frameworka Qt (nie trzeba znać frameworka, aby wywnioskować, co robi kod).

Main.cpp

#include <qcoreapplication.h>
#include <qtranslator.h>
#include <qlocale.h>

void loadLanguageSameAsLanguageOfOperatingSystem(QTranslator& translator);

QLocale::Language getLanguageOfOperatingSystem();

int main(int argc, char* argv[])
{
	QCoreApplication application(argc, argv);

	QTranslator translator;
	loadLanguageSameAsLanguageOfOperatingSystem(translator);
	application.installTranslator(&translator);

	return application.exec();
}

void loadLanguageSameAsLanguageOfOperatingSystem(QTranslator& translator)
{
	const QString pathInOperatingSystemToFolderWithTranslations = "translations";
	switch (getLanguageOfOperatingSystem()) {
	case QLocale::Polish:
		translator.load("Polish", pathInOperatingSystemToFolderWithTranslations);
		break;
	default:
		translator.load("English", pathInOperatingSystemToFolderWithTranslations);
		break;
	}
}

QLocale::Language getLanguageOfOperatingSystem()
{
	const QLocale locale;
	return locale.language();
}

Teraz chcąć to przepisać na kod obiektowy są dwie możliwości:

1. Skorzystać z dziedziczenia publicznego, czyli relacji jest-czymś.
2. Skorzystać z zawierania, czyli relacji ma-coś.

Pytanie: Która z powyższych opcji będzie najlepsza i dlaczego?

PS W komentarzu są te dwie opcje w kodzie.

Comments

Wersja z dziedziczeniem publicznym:

Translator.h

#pragma once

#include <qtranslator.h>
#include <qcoreapplication.h>
#include <qlocale.h>

class Translator : public QTranslator {
public:
	void setLanguageSameAsLanguageOfOperatingSystem(QCoreApplication& application);

private:
	QLocale::Language getLanguageOfOperatingSystem() const;
};

Translator.cpp

#include "Translator.h"

void Translator::setLanguageSameAsLanguageOfOperatingSystem(QCoreApplication& application)
{
	const QString pathInOperatingSystemToFolderWithTranslations = "translations";
	switch (getLanguageOfOperatingSystem()) {
	case QLocale::Polish:
		load("Polish.qm", pathInOperatingSystemToFolderWithTranslations);
		break;
	default:
		load("English.qm", pathInOperatingSystemToFolderWithTranslations);
		break;
	}
    application.installTranslator(this);
}

QLocale::Language Translator::getLanguageOfOperatingSystem() const
{
	const QLocale locale;
	return locale.language();
}

Main.cpp

#include <qcoreapplication.h>
#include "Translator.h"

int main(int argc, char* argv[])
{
	QCoreApplication application(argc, argv);

	Translator translator;
	translator.setLanguageSameAsLanguageOfOperatingSystem(application);

	return application.exec();
}

Wersja z zawieraniem:

Translator.h

#pragma once

#include <qtranslator.h>
#include <qcoreapplication.h>
#include <qlocale.h>

class Translator {
public:
	void setLanguageSameAsLanguageOfOperatingSystem(QCoreApplication& application);

private:
	QLocale::Language getLanguageOfOperatingSystem() const;

	QTranslator translator;
};

Translator.cpp

#include "Translator.h"

void Translator::setLanguageSameAsLanguageOfOperatingSystem(QCoreApplication& application)
{
	const QString pathInOperatingSystemToFolderWithTranslations = "translations";
	switch (getLanguageOfOperatingSystem()) {
	case QLocale::Polish:
		translator.load("Polish.qm", pathInOperatingSystemToFolderWithTranslations);
		break;
	default:
		translator.load("English.qm", pathInOperatingSystemToFolderWithTranslations);
		break;
	}
    application.installTranslator(&translator);
}

QLocale::Language Translator::getLanguageOfOperatingSystem() const
{
	const QLocale locale;
	return locale.language();
}

Main.cpp

#include <qcoreapplication.h>
#include "Translator.h"

int main(int argc, char* argv[])
{
	QCoreApplication application(argc, argv);

	Translator translator;
	translator.setLanguageSameAsLanguageOfOperatingSystem(application);

	return application.exec();
}

 

---

Nie przesadzasz z długościami nazw?

Answer 1

Nie podoba mi się modyfikowanie przekazanego argumentu, bo to jest takie... proceduralne :P Klasa modyfikuje swoje pola a nie argumenty metod.

Jestem zdania, że nie należy opakowywać funkcjonalności ustawienia jezyka jako całości w jedną klase tylko wyodrębnić czego nam brakuje i napisać klasa dla tej brakującej funkcjonalności. Bez dublowania tego co już udostępnia QTranslator i QLocale.

Tak na prawdę brakuje mapowania QLanguage na nazwe pliku.

Można pomyśleć nad klasą propertisową, która zwróci ścieżke pliku z tlumaczeniem danego języka.

Ale można też generować nazwy dynamicznie. Zauważ, że jest metoda:

QString QLocale::languageToString(QLocale::Language language)

dzięki, której zamiast tego szpetnego switch case'a można napisać:

	if (!this->translator.load(languageToFileName(locale.language())))
		this->translator.load(languageToFileName(QLanguage::English));
	app.installTranslator(&this->translator);

Pytanie gdzie umieścić languageToFileName:

QString languageToFileName(QLanguage lang) {
	return QLocale::languageToString(lang) + ".qm";
}

W ostatecznosci jako prywatna metoda aplikacji, ale lepiej w jakiejś klasie propertisowej razem ze sciezkami do innych rzeczy.

pathInOperatingSystemToFolderWithTranslations 

Plus za deskryptywne nazwy, ale z tak długą nazwą nie da się pracować. Wyobraź sobie, że potrzebujesz napisać tą nazwe 2 czy nawet 3 razy w jednej linijce. "translationsDirPath" mówi tyle samo.

 

Answer 2

Może będziesz zdziwiony ale jedna z możliwych odpowiedzi to ta: żaden z powyższych. Tłumaczenie to wymaganie aspektowe które nadaje się do ew. implementacji  przez politykę. To jest ta sama kategoria wymagań jaka obowiązuje dla wymagań "szerokiego bezpieczeństwa" czy logowania zdarzeń. Są takie wymagania które "kroją aplikację po całości".

Oczywiście jeśli nie masz wyboru lub aplikacja jest mała i nie ma wydzielonej warstwy gdzie możesz sensownie to zaimplementować, zawieranie będzie lepsze bo łatwiejsze do potencjalnej zmiany i rozwijania aplikacji.