[SIForge.org] Configurazione Programmativa: concetti di design

yag (17 gen 2005, 10:41:53)

Titolo : Modificare Factory Method parametrico: Allora ho un implementazione da manuale del factory method parametrico, ora mi servirebbe un consiglio su come fare per estenderlo e fare in modo : che il client possa passare / ricevere una classe fra alla classe prodotto Sto tentando varie strade ma questa volta non riesco ad uscirne fuori...

yag (22 nov 2004, 15:18:20)

grazie comunque ... :) in generale mi sono trovato costretto ad usare un enumerativo poterlo utilizzare il client e conoscere lo stato...

Stefano Fago (22 nov 2004, 10:31:07)

Mi spiace sinceramente del tipo di risposta che fornisci...Ho cercato solo di aiutarti...Sono stato molto concreto se leggi bene...Non penso che ti apettassi la stesura di un programma...Comunque sei vuoi ancora più concretezza vai su un classico http://www.tutok.sk/fastgl/download/books/Thinking%20in%20Patterns%20with%20Java.pdf. (Pensa in Pattern di Eckel)...Se poi non ti ritrovi ai conti...Scrivi un articolo sulla tua problematica, come l'hai risolta, cosa non ti piace di quello che hai fatto ed aprire così una discussione meno vaga e più costruttiva...senza pseudo codice o, a questo punto, fumosità di design...Mi sembra una proposta onesta...Buon Lavoro

yag (19 nov 2004, 17:21:55)

Più o meno conosco giù le problematica di cui mi hai parlato solo mi servivano risposte più concrete (a questo punto) forse il mement mi può dare una mano.. ora vedo...

Stefano Fago (17 nov 2004, 09:15:50)

La problematica che proponi ha differenti risposte...Assestiamo però le differenze...Lo State Pattern ti permette di "cristallizzare" i possibili stati di un oggetto in differenti "oggetti di stato"...Esempio: un auto è accesa, accesa ma ferma, spenta; avremo l'oggetto CAR e gli oggetti RunningState, RunningButNotMovingState, StoppedState! L'elaborazione sull'elemento target a questo punto si traduce in sequenze di passaggio di stato, quindi, il passaggio tra un oggetto stato ad un altro!...Riprendendo l'esempio: RunningButNotMovingState-->RunningState-->RunningButNotMovingState-->StoppedState!...LA conoscenza degli internals di un oggetto senza violarne l'incapsulamento(E' QUESTA LA VERA SFIDA!!!) è gestita dal pattern MEMENTO (http://www.mokabyte.it/1999/04/AT_Memento.html) e sue variazioni...E' possibile semplificarsi la vita con il pattern OBSERVER, "se le condizioni lo permettono": stiamo parlando di ricondursi ad un sistema ad eventi per cui l'evento porta con se alcune info dello stato dell'osservabile agli osservanti!...A volte lo stato deve anche essere reversibile e quindi, se lo stato stesso è risultato di un'azione, si gioca con il pattern COMMAND!...Come vedi ci sono tanti modi di approcciare, ma come la solito: CERCA DI CAPIRE PRIMA IL PROBLEMA, POI MODELLALO ED INFINE PATTERNIZZA!!!! Buon Lavoro!

yag (13 nov 2004, 15:12:27)

ciao tornato :) vorrei sapere ne design patter state come potrebbe fare il client per conosce lo stato attuale ? dell'oggetto o eventualmetne di se stesso?

yag (02 nov 2004, 18:43:24)

grazie come sempre molto chiaro. Non vorrei fare un dibattito molto lungo (anche se non nego mi farebbe piacere) forse dovrei approffondire il concetto di "programmazione funzionale"

Giovanni Giorgi (02 nov 2004, 15:44:32)

Ciao, in generale il ragionamento che hai fatto e' corretto. Il contesto presentato rientra nell'annoso problema della programmazione funzionale che va sotto il nome di "GESTIONE DEGLI ERRORI". Una delle soluzioni piu' classiche e' quella dell'ANSI C (vedi la gestione degli errori di I/O, l'uso della varaibile "errorno" ecc). La tua proposta e' buona pero' tipicamente si rischia di "ingrassare" il diagramma degli stati dell'oggetto con stati di errore, che spesso non hanno molto a che fare con il nocciolo del problema. Cioe' a regime l'oggetto inizia a preoccuparsi troppo di tutti i possibili errori, e rischia di perdere di vista il suo lavoro (un po' come una persona apprensiva che invece di lavorare si preoccupa degli errori che POTREBBE fare lavorando... :). Per evitarlo, e' stato introdotto il concetto di Eccezione, presente in linguaggi come Eiffel, C++, Java. Per una trattazione esaustiva delle eccezioni rimando a http://www.siforge.org/articles/2003/03/23-design-eccezioni-java-jdk14.html ed al libro di Stroustrup sul C++

yag (30 ott 2004, 18:44:42)

Creare una sorta di pattern Scopo: ------ Rendere il codice più chiaro e pulito Applicabilità: -------------- In quei casi in cui si una operazione (metodo) che chiama tante piccole operazioni (metodi) , se uno di questi fallisce, fallisce anche quello che le chiama, inoltre questo metodo può essere fermato da un'evento generato nel metodo chiamato Esempio classico: da un metodo di una classe ne chiami n se una di queste fallisce oppure da una di queste viene generato un evento che deve far fallire il primo. Es pseudo codice: classe::metodo1() { if (!m1) esci (ved *1.) if (!m2) esci (ved *1.) se uno di questi fallisce torna errore. } *1) implementazione di mX if (utente preme ok) torna ok if (utente preme false) torna false if (utente preme chiudi) chiudi (fa fallire il metodo metodo1) //nota: se torno false al metodo chiamante non posso sapere se è per un errore oppure per un'altro evento (Chiudi) che non sia un'errore . Ho pensato questa soluzione. la classe in questione è una specie di Facade(rappresente la mia classe application) che fornisce dei servizi delegando le richieste ad altre classi. Quello che ho pensato è: dare alla classe (in questione) uno stato (es: di errore, di attesa, chiusura ecc.) ed in base al suo stato eseguire detterminate operazioni nel mio caso specifico m2 dovrebbe chiamare (sono già in connessione) qualcosa tipo: classe->cambia_stato_in_chiudi , questo verra verificato dentro quella specie di loop e risolvo il problema. Chiudo altrimenti mi dilungo troppo. 1) Secondo te è corretto il concetto di stato ? (in fin dei conti una app. può avere uno stato...) lo userai anche in altri casi naturalmente 2) uno stato che caratteristiche potrebbe avere (nome,catergoria, priorità ) altro ? Scusa ancora il disturbo grazie ancora.