Pratiche di programmazione modulare

Question

Pratiche di programmazione modulare

#1 da (2 voti)

0

Mentre comincio a codificare sempre di più, ad esempio in C ++, tendo anche a voler saperne di più sugli standard accettati per il codice.

Sto provando a codificare un motore di scacchi in questo momento, ma non sono sicuro di come trattare ciascun "modulo" del programma (che è separato in file diversi).

Ad esempio, ha senso creare una classe per bitboard come bitboard.h e bitboard.cpp , in quanto potrebbe essere richiesta in seguito. Ma non ha senso avere una classe per il generatore di movimento, perché non avrò mai bisogno di più di un generatore di movimento.

Ma voglio ancora rispettare il principio di minimum privilege e non dare agli utenti l'accesso a più funzioni del necessario. Ma non sono sicuro che tu possa farlo senza una lezione? Ho esaminato namespace , ma non sono sicuro di come si applicherebbe in questo caso.

In che modo i programmatori professionisti gestiscono questo genere di cose? Ho esaminato la fonte del Stockfish motore di scacchi open source, e ha sia file di intestazione che file cpp, ma i file di intestazione sembrano semplicemente avere un sacco di variabili.

programming-practices c++

posta Shreyas 12.07.2015 - 14:35

fonte

1 risposta

Leggi altre domande sui tag programming-practices c++

Come importare dettagli del driver e dettagli di connessione senza scriverlo manualmente o con hard coding? Che cosa dovrebbero rappresentare i file e la cartella (Core, Risorse, Comune, Modelli, Risorse, Viste) nel mio progetto?

score 2 · Accepted Answer

Il principio del minimo privilegio riguarda la sicurezza, non l'ingegneria del software e non deve essere confuso con Encapsulation . Sono due cose molto diverse.

Il punto del principio del privilegio minimo è di dare a un utente (o applicazione) il minimo indispensabile di autorizzazioni di cui ha bisogno. Pertanto, l'utente A può ottenere un set di autorizzazioni diverso rispetto all'utente B. Ciò serve a rendere difficile agli utenti malintenzionati l'accesso a funzionalità potenzialmente pericolose, in quanto richiede l'autorizzazione esplicita.

L'incapsulamento consiste nel chiarire quali parti della classe si intendono per utenti esterni e quali parti devono essere ignorate dal chiamante. Lo scopo qui non riguarda gli utenti malintenzionati, ma piuttosto quello di assicurarsi che gli utenti non scrivano accidentalmente codice che dipende da cose che potrebbero cambiare in futuro. Spinge anche gli autori di classe a creare interfacce chiare.

Inerente al principio del minimo privilegio è che utenti diversi hanno permessi diversi. Non vi è alcuna idea di ciò in tutto nel software Object Orient. Tutti gli utenti delle tue classi hanno lo stesso accesso. Anche implicito nel Principio del Privilegio Minimo è che stai forzando gli utenti in un sottoinsieme limitato. Al contrario, l'incapsulamento può essere facilmente rotto in molte lingue orientate agli oggetti. (In alcuni, come Python, l'incapsulamento è interamente gestito con standard di codifica.)

Se si tenta di progettare classi con un occhio per limitare al minimo gli utenti (come per il Principio del Privilegio minimo), si rischia di finire con classi limitate e difficili da usare. Invece, dovresti guardarlo dal punto di vista di "cosa vogliono fare gli utenti con questa classe". L'interfaccia pubblica è tutto ciò che puoi pensare che gli utenti vorranno fare. Quindi rendi tutto il resto privato. È incapsulamento.

In sostanza, quando si progettano le classi, si desidera operare con un occhio per dare agli utenti il privilegio più che si può tranquillamente dare loro.