Il "salto di fila" in un'API è una violazione della "singola responsabilità"?

Question

Il "salto di fila" in un'API è una violazione della "singola responsabilità"?

#1 da (5 voti)
#2 da (3 voti)

0

Il link descrive un'API per enumerare le righe (costituite da diversi valori) di dati.

In questa API è possibile recuperare i valori dalla riga corrente e "saltare" alla riga successiva.

Secondo me, questo è un misdesign. Viola la regola della singola responsabilità: lo stesso oggetto è responsabile dell'enumerazione alla riga successiva e del recupero dei valori dalla riga. Sei d'accordo sul fatto che viola lo SRP?

Mi sembra che il progetto giusto sia quello di recuperare gli oggetti delle righe (che non sono elaborati nella versione attuale dell'API) e utilizzare gli oggetti riga per recuperare i valori.

A parte la singola responsabilità, quali altre regole (se esistenti) del buon software progettano questa API viola?

(Sto scrivendo i binding per questa API C nel linguaggio di programmazione Ada, quindi penso di avvolgerlo in un elaborato wrapper orientato agli oggetti.)

api-design api design-patterns object-oriented-design

posta porton 16.08.2017 - 22:32

fonte

2 risposte

Leggi altre domande sui tag api-design api design-patterns object-oriented-design

Come fornire internamente le librerie Java? Argomenti multipli rispetto a un argomento di tupla

score 5 · Answer 1

Nel tuo approccio al problema, ci sono essenzialmente due tipi di oggetti: una riga e un iteratore su una sequenza di righe. Una riga dovrebbe avere una conoscenza dei suoi contenuti, dei suoi valori. Un iteratore dovrebbe avere una conoscenza delle righe e solo delle righe, non dei loro contenuti.

Guardando la documentazione, mi sembra che gli autori di Rasqal RDF Query Library usassero un approccio diverso. Non ci sono due oggetti, ma solo uno: il cursore . Il cursore ha una conoscenza della voce corrente e ha anche una conoscenza della voce successiva.

Sebbene il tuo approccio sia più familiare a molti sviluppatori, il cursore è ancora comunemente usato nelle librerie di accesso ai dati, come le librerie che si occupano di SQL. Queste librerie solitamente non usano il pattern iteratore e forniscono al chiamante solo un cursore che ha due metodi: uno per leggere il contenuto della riga corrente del database; l'altro per passare alla riga successiva.

Se il wrapper orientato agli oggetti è destinato agli sviluppatori che non hanno familiarità con le librerie di accesso SQL di basso livello, ma che sanno bene come lavorare con gli iteratori, usa il pattern iteratore.

Se, d'altra parte, stai scrivendo il tuo wrapper per gli sviluppatori che hanno familiarità con SQL e il concetto di cursori, segui la seconda rappresentazione. Un iteratore mette probabilmente troppa astrazione sull'API C e potrebbe rapidamente diventare un'interfaccia leaky.

score 3 · Answer 2

La tua visione della "singola responsabilità" è molto, molto, troppo stretta. Lo chef in un ristorante è responsabile della produzione di colazione, pranzo, cena, inclusi antipasti, portate principali e doposcuola. Questa è la sua unica responsabilità. Non hai cinque chef diversi per questo. O un altro chef la cui responsabilità è quella di produrre una cena particolare.

L'API è responsabile per l'accesso al database. Questa è la sua unica responsabilità, ed è quello che fa. Se calcolasse anche le fasi lunari, ciò sarebbe contrario al Principio di Responsabilità Unica.