Un aiuto teorico sulla OOP

di il
4 risposte

Un aiuto teorico sulla OOP

Salve a tutti del forum,
Premetto che sto sviluppando una mia libreria composta da diversi package e in ognuno di questi vi sono diverse classi.

I package sono chiamati per argomenti ossia del tipo: swing / stream / utility / exception.
Le classi delle utility, ad esempio, mettono a disposizione una serie di metodi statici per diverse attività. Le classi del package stream invece gestiscono vari formati di file tra cui testo / xml / etc.

Premetto che ogni classe può utilizzare istanze di altre classi presenti nei vari package!!

[PREMESSA]
Ora, per quanto riguarda il package "exception", questo package contiene una classe la quale deriva dalla classe delle eccezioni. Questa classe consente di gestire una eccezione lanciata dall'utilizzatore della classe, dando la possibilità di registrare, su richiesta, determinate informazioni in un file log ad esempio di testo.

[PREMESSA]
Nel package stream vi è una classe astratta che definisce i metodi standard e tutte le altri classi devono ereditare i metodi. Domanda al volo conviene un'interfaccia o una classe astratta?

Le classi che gestiscono i file (una classe per tipo) ridefiniscono i metodi in base alla tipologia di file. In caso di problemi queste classi usano la "classe delle eccezioni" per registrare nel log i problemi chi ci sono stati durante l'esecuzione.

La mia perplessità è:
La classe che gestisce le eccezioni, può utilizzare la classe che gestisce lo stream di file per registrare i dati ? Oppure conviene una classe privata a parte per gestire il file dei log?

La mia preoccupazione è che possa nascere un problema di ricorsività ossia:
classe streamX -> Registrazione -> Evento Errore -> Lancio Exception -> Registrazione errore
-> classe streamX -> Registrazione -> Evento Errore->.....loop!!!!

Secondo alcuni testi le classi non devono essere dipendenti l'una all'altra e credo che a questo l'ho assolto ma da come si sta mettendo sembra che la cosa possa avere una ricorsività sugli eventi. Oppure sono entrato nel pallone!!!!!

Mi dimenticavo, come linguaggio sto utilizzando Java8

Grazie per aver letto e scusate se il testo è lungo.

Saluti

4 Risposte

  • Re: Un aiuto teorico sulla OOP

    Rileggendo quello che ho scritto, secondo me mi sono dilungato troppo entrando in dettagli poco significativi.

    Riassumendo brevemente diventa così:
    n° scenari: 2
    Classe A: Gestione file dati
    Classe B: Gestione eccezione e registrazione file dati
    Attività: Ogni classe usa l'altra per le proprie attività.

    Scenario attuale:
    Classe A -> I Metodi Statici utilizzano istanze della classe B per lanciare eccezioni se ci sono problemi sui file.
    Classe B -> I Metodi utilizzano i metodi della classe A per registrare i dati.
    Pro: Una classe A e una B
    Contro:
    Se il metodo della classe A va in errore perchè non riesce ad aprire/salvare un file, lancia un'eccezione mediante metodo della classe B.
    Il metodo della classe B, utilizzerà i metodi della classe A per registrare il suo log in un file.
    Se nel tentativo di salvare il file il metodo della classe A fallisce, allora ci si ritroverebbe in un loop ossia un'altro lancio di eccezione, successivamente tentativo di salvare i dati, lancio eccezzione, tentativo e cosi via.

    Scenario alternativo:
    Classe A -> I Metodi statici utilizzano istanze della classe B per lanciare eccezioni. (come sopra)
    Classe B -> I metodi utilizzano i metodi di un'altra classe (simile alla classe A) che non fa uso di lanci eccezioni ed è locale.
    Pro: sembra che abbia risolto il problema del possibile loop.
    Contro: Ho praticamente riscritto due volte la stessa classe!!!!!!!!!

    Domanda ci sono dritte in merito?

    Saluti
  • Re: Un aiuto teorico sulla OOP

    Non ho capito molto della tua spiegazione, ma fondamentalmente il problema e' questo (ed e' un problema classico ):

    se tu crei un livello di astrazione, la sua implementazione non deve usare lo stesso livello di astrazione!

    In questo caso, la classe di gestione delle eccezioni non deve usare la classe di gestione dei file per fare il lavoro, ma un livello di astrazione inferiore, se no ti trovi nel casino che hai descritto, visto che la classe di gestione dei file usa la classe di gestione delle eccezioni.

    Se ti trovi ad avere due implementazioni simili, allora ti serve uno strato intermedio contenente il codice comune.

    L'uso dello stesso livello di astrazione per implementare qualcosa lo si puo' fare quando questo qualcosa ha una definizione ricorsiva. Ma in questo caso:

    1) l'implementazione si trova tutta nello stesso package, e magari nella stessa classe
    2) c'e' la base della ricorsione che termina il ciclo ricorsivo.


    Metodi statici?
    Meglio un singleton.
  • Re: Un aiuto teorico sulla OOP

    Ok, hai centrato il problema.

    In effetti sono finito, inavvertitamente, a trovarmi in una condizione di ricorsività in determinati casi. CHE FREGATURA!!!!

    Tutte le classi della libreria (distribuite in package per argomento) utilizzano le classi Oracle per mettere a disposizione di un'applicativo, metodi più complessi. Solo il gestore delle eccezioni che in genere si limita a riportare la condizione di errore, doveva invece effettuare delle operazioni di registrazione e per far questo utilizzava le classi dello stesso livello di astrazione.

    Quindi, come dici te, dovrei rifare la classe Exception che non utilizzi classi della libreria stessa ma inglobi tutto. Della saga se la canta e se la suona!!

    Grazie
    nick

    P.S.: Scusa se all'inizio mi sono spiegato male, credo che ero nel pallone.
  • Re: Un aiuto teorico sulla OOP

    cnesan ha scritto:


    Quindi, come dici te, dovrei rifare la classe Exception che non utilizzi classi della libreria stessa ma inglobi tutto. Della saga se la canta e se la suona!!
    Non so cosa tu stia facendo ma non credo sia tra le soluzioni migliori. Avere una classe che "ingloba" tutto e che "se la canta e se la suona" non è una buona pratica.

    In questo modo violeresti l'SRP (Single Responsability Principle).
Devi accedere o registrarti per scrivere nel forum
4 risposte