Sovrascrittura classe di un altro progetto...

[Fire Fox II]

Salve raga

allora ho bisogno di creare un progetto simile ad uno già esistente che discostano per alcuni classi completamente diverse...

Faccio un esempio per rendere meglio l'idea

Ho il seguente progetto così composto

Nome progetto1
Classe Principale
Classe operazioniA
Classe operazioniB

Il nuovo progetto invece

Nome progetto2
Classe Principale2 extends Principale
Classe operazioniB

Dovrei fare in modo che il progetto2 legga la classe operazioniB del suo insieme e non di progetto1...
Credevo che dando lo stesso nome automaticamente la classe del progetto1 venisse sovrascritta ma non è così...

Come posso ovviare?

Thanks

[valia]

fammi capire.
Tu hai la libreria pippo, dentro c'è la classe Pluto. Vuoi che dentro pippo ogni volta che vedi Pluto riferisca Pluto1 (con la tua modifica)?

[Fire Fox II]

Precisamente

[valia]

no, detta così non lo puoi fare.
Sono due package differenti e pippo non può mai conoscere cosa il mondo fa con una sua classe.
Dovresti prendere i sorgenti di pippo, aggiungere la classe estesa, modificare i riferimenti e a quel punto hai quello che vuoi.

[Fire Fox II]

Scusami io oggi casualmente ho notato una cosa......

Parto di nuovo da un esempio per cercare di rendere più chiaro ciò che mi serve...
La classe principale ha un tasto che chiama un metodo contenuto in Principale.operazioniB
Io estendendo e facendo partire il programma da Principale2, volevo che quel tasto chiamasse il metodo contenuto in Principale2.operazioniB ...

Lavorando in Netbeans e facendo partire il software tramite esso in modalità debug non ottenevo ciò che mi serviva...
Oggi ho creato il jar ed avviando da qui invece ottengo il risultato che cercavo

Forse creando il jar effettivamente le classi vengono sovrapposte come non avviene nella modalità "live" di Netbeans ?

Però è una rottura... Non posso sempre creare il jar per fare le prove del caso........

[valia]

1. togli tutti i metodi di logica dalle GUI. Il fatto che tu hai un metodo che fa "operazioni" non è corretto.
Le tue operazioni devono stare in un punto a parte (a volte anche package differenti) perché sono cose differenti. La GUI si DEVE limitare a chiamare il metodo che ti interessa, non a fare logica. Ti può sembrare la stessa cosa, ma in realtà non lo è.
2. togli tutti i metodi di logica dalla GUI (parte II): puoi avere dei dati che prendi da caselle di testo o che. Richiamarle da un'altra classe è concettualmente errato, non sai cosa è valorizzato bene e cosa no e puoi avere risultati errati.

A maggior ragione se ti accorgi di una parte di logica che devi usare in 2 punti differenti, la stai posizionando in partenza male.

Poi l'altra volta io ti ho fatto una domanda specifica e tu mi hai detto si.
Da quello che scrivi (italiano si, comprensibile no) si evince che hai una libreria (quindi un jar) pippo che dentro ha Pluto. Da un'altra parte (e non hai detto dentro la stessa libreria) vuoi estendere Pluto e fare in modo che pippo dove scrivi Pluto legga Pluto2. Ti ho detto che questo è errato.
Adesso tu mi dici che il package è unico e che hai i sorgenti. Ovvio che se estendi una classe, esegui il metodo riscritto, a condizione che nel momento in cui istanzi il tuo oggetto, attribuisci a questo una istanza di tipo Pluto2 e non di tipo Pluto.

Quando lavori devi ANCHE provare ad eseguire senza l'IDE, perché ogni IDE si porta dietro delle librerie, dipendenze che vai a specificare in modo facile con l'interfaccia grafica, ma che poi ti scordi di esportare o di considerare.
In realtà crei un jar per tutte le prove del caso, si chiama "fare il developer".