Lepsza wersja kodu.

Question

Witam, która z poniższych wersji kodu będzie Twoim zdaniem lepsza i dlaczego?

Wersja 1:

MessageSender.h

#pragma once

#include <string>

class MessageSender {
public:
	bool send(const std::string& message);

private:
	bool isAllowed(const std::string& message) const;
};

MessageSender.cpp

#include "MessageSender.h"

bool MessageSender::send(const std::string& message)
{
	if (isAllowed(message)) {
		//kod wysylania wiadomosci
		return true;
	}
	return false;
}

bool MessageSender::isAllowed(const std::string& message) const
{
	//kod sprawdzajacy, czy wiadomosc jest dozwolona
	//na przyklad czy nie jest pusta i czy nie jest wulgarna
}

Wersja 2:

MessageSender.h

#pragma once

#include <string>

class MessageSender {
public:
	bool isAllowed(const std::string& message) const;

	void send(const std::string& message);
};

MessageSender.cpp

#include "MessageSender.h"

bool MessageSender::isAllowed(const std::string& message) const
{
	//kod sprawdzajacy, czy wiadomosc jest dozwolona
	//na przyklad czy nie jest pusta i czy nie jest wulgarna
}

void MessageSender::send(const std::string& message)
{
	//kod wysylania wiadomosci
}

Podsumowywując, w wersji pierwszej użytkownik jest zabezpieczony przed popełnieniem błędu związenego z nie wywołaniem metody isAllowed. Jednak z drugiej strony może to być mylące, jeżeli użytkownik nie spojrzy na typ wartości zwracanej, to może się okazać, że uzna on wiadomość za wysłaną, kiedy wcale taką nie jest. W wersji drugiej to użytkownik jest zobowiązany do wywołania metody isAllowed przed wywołaniem metody send. Takie rozdzielenie umożliwia użytkownikowi zdecydowanie, czy chce on wysyłać również wiadomości niedozwolone.

Answer 1

Moim skromnym zdaniem, lepiej tutaj wykorzystać klasę abstrakcyjną i implementować zabezpieczenia zależnie od potrzeb użytkownika. Następnie oddzielna klasa sendera pobierałaby przy wywołaniu metody wysyłającej obiekt walidatora, zaimplementowany ręcznie lub z puli gotowych (np. sprawdzający obecność wulgaryzmów itp.). Takie rozwiązanie nie zamyka użytkownika na jeden sposób weryfikacji. Bo równie dobrze może użyć pustego walidatora, który po prostu zwraca prawdę dla każdych danych.

Comments

Dziękuję za odpowiedź. Mam jeszcze jedno pytanie, czy jest sens wykorzystania klasy abstrakcyjnej już teraz, jeżeli wiem, że algorytm do walidacji najprawdopodobniej będzie stały?

Uogólniając, czy lepiej jest poczekać z decyzją o wprowadzeniu abstrakcji do momentu wystąpienia powtórzeń, czy może odrazu implementować oczywiste abstrakcje?

---

Kod powinno pisać się od samego początku w uniwersalny i rozszerzalny sposób. Nie ma znaczenia, czy algorytm będzie stały, bo narzut wydajnościowy polimorfizmu jest tak mały, że praktycznie nic nie tracisz z jego użycia, a zyskujesz bardzo wiele. Twój projekt podziękuje ci za to w przyszłości (bo sam nawet nie wiesz, kiedy wpadnie ci do głowy pomysł zmiany implementacji).

Answer 2

W wąskim ujęciu, wersja 1 będzie lepsza. Równie ważkim argumentem że "może nie sprawdzić" jest "jak to nie sprawdzi... to przecież jest w jego interesie żeby wiedzieć". Rozbicie na 2 wywołania (2 przykład), zawsze silniej wiąże klasy bo i interfejs będzie bardziej złożony.

W szerszym ujęciu, zgadzam się z @Patrycerz. Istnieje ryzyko że pojawią się tam i inne algorytmy dopuszczenia do wysłania lub strategie doręczenia. Nie wiem tylko czy decydował bym się na klasę abstrakcyjną czy wystarczyło by lżejsze rozwiązanie. No ale o to nie pytałeś.

Comments

Nie wiem tylko czy decydował bym się na klasę abstrakcyjną czy wystarczyło by lżejsze rozwiązanie.

Nie powinniśmy bać się używania klas abstrakcyjnych (lub ogólniej nazywając, abstrakcji). W C++ jest to dosyć wydajne rozwiązanie, a logika kodu dzięki jej wykorzystaniu staje się bardziej przejrzysta i uniwersalna. Na przykład w Javie na każdym kroku może znaleźć implementacje różnych interfejsów, nawet w prostych bibliotekach. Moim zdaniem powinniśmy wykorzystywać wszystkie idee związane z programowaniem obiektowym, bo zyskujemy dzięki temu bardzo dużo, płacąc za to cenne minimalnie większego kodu.

---

virtual/crtp/template/functional... raczej tak to rozważam... być może prosta strategia. Virtual jest piekielnie ciężki. Poza tym Java to nie C++ na szczęście co do ograniczonych wyborów.