Sarebbe una cattiva progettazione astrarre una libreria grafica e avvolgerla in una singola classe? [duplicare]

Question

Sarebbe una cattiva progettazione astrarre una libreria grafica e avvolgerla in una singola classe? [duplicare]

#1 da (2 voti)
#2 da (2 voti)

1

Sto avviando un progetto di gioco in C ++ usando SFML.

Fornisce varie classi per la gestione di grafica, input, ecc., ma mi piacerebbe racchiudere tutto in una sola classe Media .

Credo che così facendo, potrei semplificare i miei sforzi e far sì che la classe si prenda cura dei dettagli, limitando la quantità di codice che devo scrivere e quindi limitando le possibilità che un bug mi sfugga di vista.

Tuttavia, ho letto più volte che le lezioni monolitiche e fai-da-te come questa potrebbero non essere una buona idea.

Perché?

object-oriented design c++ game-development

posta jcora 10.02.2013 - 11:31

fonte

2 risposte

2

Perché ogni volta che devi cambiare qualcosa, scoprirai che ha un impatto su tutto . Inoltre, una classe può avere solo una vita, mentre in realtà si desidera avere diverse vite per diversi componenti diversi, ad esempio, si desidera che ogni sprite abbia una durata diversa.

risposta data 10.02.2013 - 12:40

fonte

Leggi altre domande sui tag object-oriented design c++ game-development

Multitasking in C # Il management vuole un'API nel software acquistato

score 2 · Accepted Answer

Would it be bad design to abstract a graphics library and wrap it in a single class?

La risposta è: non necessariamente! Ma nel tuo caso: Probabilmente!

Immagino che quello che stai cercando di fare abbia anche un nome: si chiama pattern di facciata e viene usato per semplificare le routine complesse e le dipendenze sequenziali per l'utente.

It provides various classes for handling graphics, input, etc, but I would like to wrap it all up in a single Media class.

Sento un cattivo design OO qui perché assegni a una classe molteplici responsabilità. Input Handling non dovrebbe condividere il codice con le routine grafiche. Questa classe potrebbe benissimo aggiungere qualcosa di non realizzabile alla fine.

However, I have read several times that monolithic, do-it-all classes such as this might not be a good idea.

Why is that?

Riguarda la manutenibilità. Stai accoppiando cose che non appartengono insieme, e ogni parte del tuo sistema che la usa poi ha un strong accoppiamento con queste cose. Permettetemi di darvi un rapido esempio di codice che ho visto di recente:

//bad! This is in a data access class! I have effectively coupled it to web libraries by using HttpServletRequest
public List<Reason> getReasons(HttpServletRequest request, String filter) {
    Locale locale = request.getLocale();
    //get reasons and process according to locale
}

//much much better: No coupling/dependencies to web environment
public List<Reason> getReasons(Locale locale, String filter) {
    //get reasons and process according to locale
}

Pensa a questo esempio: se usassi quella classe in Desktop-Application, avrei comunque tutte le cose del web lì, solo perché qualcuno ha deciso di usare HttpServletRequest. Sarebbe una dipendenza inutile.

Potresti chiedere come questo sia direttamente correlato alla tua domanda, e la risposta è: si tratta di dipendenze / accoppiamenti. Più dipendenze, più forti sono i tuoi accoppiamenti, più difficile sarà il tuo codice da riutilizzare o migliorare o mantenere senza portare in giro molta spazzatura o usando brutti hack.