State dichiarando variabili STL in una definizione di classe troppo rivelatrice?

Question

State dichiarando variabili STL in una definizione di classe troppo rivelatrice?

#1 da (6 voti)
#2 da (4 voti)
#3 da (0 voti)

0

Se stai cercando di nascondere l'implementazione, dichiareresti che le variabili STL sono troppo rivelatrici?

// in Word_Bucket.h
class Word_Bucket {
private:
    std::vector<std::string> contents;

    ...etc
}

... ma poi se lo avvolgi, per nascondere l'implementazione, non dovresti rivelarlo comunque nell'interfaccia del wrapper?

// in Word_Bucket.h
class Word_Bucket {
private:
    Bucket contents;

    ...etc
}

// in Bucket.h
class Bucket {
private:
    std::vector<template_stuff> contents;

    ...etc
}

interfaces abstraction

posta user2738698 26.03.2014 - 20:51

fonte

3 risposte

Leggi altre domande sui tag interfaces abstraction

Quanto spesso ti rifattori o ristrutturi il tuo codice in progetti a lungo termine? [duplicare] Cosa succede se dichiarazione (evento) significa in JavaScript? [chiuso]

score 6 · Answer 1

Il punto di Nascondere Informazioni in OOP non ha alcuno scopo di segretezza . Anche senza i file di intestazione, l'ispezione dei tuoi binari può rivelare un bel po 'della tua implementazione interna.

Lo scopo di Information Hiding è di definire i limiti della black box per gli utenti di una classe con cui interfacciarsi e fornisce un contratto implicito per il comportamento previsto della classe.

Dichiarare membri pubblici o privati non è quello di tenerli segreti, è quello di separare "Qui ci sono i controlli, non preoccuparti di queste altre cose".

Se vedo un vettore in una dichiarazione di classe come membro privato, assumerò che la classe gestisca gli elementi in quel vettore e che non debba affrontarlo.

score 4 · Answer 2

Contrariamente alla risposta di whatsisname , mi sembra di pensare che l'occultamento delle informazioni tenti di non rendere utenti di un class consapevole della sua implementazione e quindi non fare assunzioni basate sull'attuale implementazione, perché idealmente questo potrebbe cambiare senza influenzare il codice utente. Detto questo, C ++ è davvero pessimo per quanto riguarda l'occultamento delle informazioni, perché gli utenti di una classe possono vedere le sue parti private. (Punito non intenzionale, ma notato.)

Come tante cose su C ++, questo è un sacrificio per le prestazioni e la retrocompatibilità: per avere oggetti basati su stack, il compilatore deve conoscere la dimensione di tali oggetti in fase di compilazione. Dato il modello di compilazione di C, questo richiede che le informazioni siano accessibili attraverso la definizione della classe.

Puoi aggirare il problema nascondendo le implementazioni dietro le classi di base polimorfiche o impiegando l'idioma dei brufoli. Ciò richiederà costi di runtime aggiuntivi, ma è quello che serve. Se C ++ avesse implementato il nascondiglio completo delle informazioni, avresti sempre pagato tutto questo.

score 0 · Answer 3

Se vuoi davvero nascondere i dettagli della tua implementazione di contents , invece di dichiararla come Bucket , dichiarala come Bucket* . Puoi procedere come segue:

// in Word_Bucket.h
class Bucket; // simple forward declaration of the type allows to use a pointer to it

class Word_Bucket {
private:
    Bucket* contents;
}

Dovrai usare new e delete nel costruttore e distruttore di Word_Bucket ma usando questa tecnica, solo Word_Bucket.cpp deve includere Bucket.h .