Come si trova un ago in un pagliaio?

https://stackoverflow.com/questions/23755

09-06-2019
|

Domanda

Quando si implementa la ricerca dell'ago in un pagliaio in modo orientato agli oggetti, si hanno essenzialmente tre alternative:

1. needle.find(haystack)

2. haystack.find(needle)

3. searcher.find(needle, haystack)

Quale preferisci e perchè?

So che alcune persone preferiscono la seconda alternativa perché evita di introdurre un terzo oggetto.Tuttavia, non posso fare a meno di ritenere che il terzo approccio sia concettualmente più "corretto", almeno se il tuo obiettivo è modellare "il mondo reale".

In quali casi ritieni che sia giustificato introdurre oggetti helper, come il ricercatore in questo esempio, e quando dovrebbero essere evitati?

Soluzione

Di solito le azioni dovrebbero essere applicate a ciò su cui stai eseguendo l'azione...in questo caso il pagliaio, quindi penso che l'opzione 2 sia la più appropriata.

Hai anche una quarta alternativa che penso sarebbe migliore dell'alternativa 3:

haystack.find(needle, searcher)

In questo caso, ti permette di fornire il modo in cui vuoi cercare come parte dell'azione, e così puoi mantenere l'azione con l'oggetto su cui si sta operando.

Altri suggerimenti

Delle tre preferisco l'opzione n.3.

IL Principio di responsabilità unica mi fa venire voglia di non aggiungere funzionalità di ricerca ai miei DTO o modelli.La loro responsabilità è essere dati, non trovare se stessi, né gli aghi dovrebbero sapere dei pagliai, né i pagliai sapere degli aghi.

Per quello che vale, penso che alla maggior parte dei professionisti dell'OO serva MOLTO tempo per capire perché il punto 3 è la scelta migliore.Ho fatto OO per un decennio, probabilmente, prima di groccarlo davvero.

@wilhelmtell, C++ è uno dei pochissimi linguaggi con specializzazione in modelli che fanno funzionare effettivamente un sistema del genere.Per la maggior parte delle lingue, un metodo "trova" per scopi generali sarebbe un'idea ORRIBILE.

Esiste un'altra alternativa, ovvero l'approccio utilizzato dall'STL del C++:

find(haystack.begin(), haystack.end(), needle)

Penso che sia un ottimo esempio di C ++ che grida "in faccia!" a Oop.L'idea è che l'OOP non è una soluzione miracolosa;a volte le cose sono meglio descritte in termini di azioni, a volte in termini di oggetti, a volte nessuno dei due e talvolta entrambi.

Bjarne Stroustrup ha affermato in TC++PL che quando si progetta un sistema si dovrebbe sforzarsi di riflettere la realtà rispettando i vincoli di un codice efficace ed efficiente.Per me, questo significa che non dovresti mai seguire nulla alla cieca.Pensa alle cose a portata di mano (pagliaio, ago) e al contesto in cui ci troviamo (cercando, ecco di cosa parla l'espressione).

Se l'enfasi è sulla ricerca, allora utilizzare un algoritmo (azione) che enfatizzi la ricerca (ad es.è flessibile per adattarsi a pagliai, oceani, deserti, elenchi collegati).Se l'enfasi è sul pagliaio, incapsulare il metodo find all'interno dell'oggetto pagliaio e così via.

Detto questo, a volte hai dei dubbi e hai difficoltà a fare una scelta.In questo caso, sii orientato agli oggetti.Se cambi idea in seguito, penso che sia più semplice estrarre un'azione da un oggetto piuttosto che dividere un'azione in oggetti e classi.

Segui queste linee guida e il tuo codice sarà più chiaro e, beh, più bello.

Direi che l’opzione 1 è completamente esclusa.Il codice dovrebbe essere letto in un modo che ti dica cosa fa.L'opzione 1 mi fa pensare che questo ago mi andrà a cercare in un pagliaio.

L'opzione 2 sembra buona se un pagliaio deve contenere aghi.ListCollections conterrà sempre ListItems, quindi fare collection.find(item) è naturale ed espressivo.

Penso che l'introduzione di un oggetto helper sia appropriata quando:

Non controlli l'implementazione degli oggetti in questione
CIOÈ:search.find(ObsecureOSObject, file)
Non c'è una relazione regolare o sensata tra gli oggetti
CIOÈ:nameMatcher.find(case,alberi.nome)

Sono con Brad su questo.Più lavoro su sistemi estremamente complessi, più vedo la necessità di disaccoppiare veramente gli oggetti.Ha ragione.È ovvio che un ago non deve sapere nulla del pagliaio, quindi 1 è decisamente fuori.Ma un pagliaio non dovrebbe sapere nulla di un ago.

Se stessi modellando un pagliaio, potrei implementarlo come una raccolta, ma come una raccolta di fieno O paglia - non una raccolta di aghi!Tuttavia, prenderei in considerazione il fatto che le cose si perdono in un pagliaio, ma non so nulla di cosa esattamente siano quelle cose.Penso che sia meglio non far cercare nel pagliaio oggetti in sé (how accorto è comunque un pagliaio).L'approccio giusto per me è che il pagliaio presenti una raccolta di cose che sono al suo interno, ma che non sono paglia, fieno o qualunque cosa dia al pagliaio la sua essenza.

class Haystack : ISearchableThingsOnAFarm {
   ICollection<Hay> myHay;
   ICollection<IStuffSmallEnoughToBeLostInAHaystack> stuffLostInMe;

   public ICollection<Hay> Hay {
      get {
         return myHay;
      }
   }

   public ICollection<IStuffSmallEnoughToBeLostInAHayStack> LostAndFound {
      get {
        return stuffLostInMe;
      }
   }
}

class Needle : IStuffSmallEnoughToBeLostInAHaystack {
}

class Farmer {
  Search(Haystack haystack, 
                 IStuffSmallEnoughToBeLostInAHaystack itemToFind)
}

In realtà c'era altro che avrei scritto e astratto in interfacce e poi ho capito quanto stavo diventando pazzo.Mi sentivo come se fossi in una lezione di informatica al college...:P

Hai capito.Penso che andare il più liberamente possibile sia una buona cosa, ma forse mi stavo lasciando prendere la mano!:)

Se sia Needle che Haystack sono DAO, le opzioni 1 e 2 sono fuori questione.

La ragione di ciò è che i DAO dovrebbero essere responsabili solo del mantenimento delle proprietà degli oggetti del mondo reale che stanno modellando e avere solo metodi getter e setter (o solo accesso diretto alle proprietà).Ciò semplifica la serializzazione dei DAO in un file o la creazione di metodi per un confronto generico/copia generica, poiché il codice non conterrebbe un sacco di istruzioni "if" per saltare questi metodi di supporto.

Resta solo l’opzione 3, che la maggior parte concorderebbe come comportamento corretto.

L'opzione 3 presenta alcuni vantaggi, il più grande dei quali è il test unitario.Questo perché ora sia gli oggetti Needle che Haystack possono essere facilmente simulati, mentre se venissero utilizzate le opzioni 1 o 2, lo stato interno di Needle o Haystack dovrebbe essere modificato prima di poter eseguire una ricerca.

In secondo luogo, con il ricercatore ora in una classe separata, tutto il codice di ricerca può essere conservato in un unico posto, incluso il codice di ricerca comune.Mentre se il codice di ricerca fosse inserito nel DAO, il codice di ricerca comune verrebbe archiviato in una gerarchia di classi complicata o comunque con una classe Searcher Helper.

Dipende interamente da cosa varia e cosa rimane uguale.

Ad esempio, sto lavorando su un progetto (non OOP) struttura dove l'algoritmo di ricerca è diverso a seconda sia del tipo di ago che di pagliaio.A parte il fatto che ciò richiederebbe un doppio invio in un ambiente orientato agli oggetti, significa anche che non ha senso scrivere neanche needle.find(haystack) o per scrivere haystack.find(needle).

D'altra parte, la tua applicazione potrebbe tranquillamente delegare la ricerca a entrambe le classi o attenersi completamente a un algoritmo, nel qual caso la decisione è arbitraria.In tal caso preferirei il haystack.find(needle) modo perché sembra più logico applicare la scoperta al pagliaio.

Quando si implementano una ricerca ad ago di un pagliaio in modo orientato agli oggetti, hai essenzialmente tre alternative:

ago.find(pagliaio)

pagliaio.trova(ago)

searcher.find(ago, pagliaio)

Quale preferisci e perchè?

Correggimi se sbaglio, ma in tutti e tre gli esempi lo hai già fatto Avere un riferimento all'ago che stai cercando, quindi non è un po' come cercare i tuoi occhiali quando sono appoggiati sul tuo naso?:P

Gioco di parole a parte, penso che dipenda davvero da ciò che consideri la responsabilità del pagliaio all'interno di un determinato dominio.Ci interessa solo nel senso che è una cosa che contiene aghi (una collezione, essenzialmente)?Quindi haystack.find(needlePredicate) va bene.Altrimenti, farmBoy.find(predicate, haystack) potrebbe essere più appropriato.

Per citare i grandi autori di SICP,

I programmi devono essere scritti affinché le persone possano leggerli e, solo incidentalmente, affinché le macchine possano eseguirli

Preferisco avere entrambi i metodi 1 e 2 a portata di mano.Usando il rubino come esempio, viene fornito con .include? che viene utilizzato in questo modo

haystack.include? needle
=> returns true if the haystack includes the needle

A volte però, puramente per ragioni di leggibilità, voglio girarlo.Ruby non viene fornito con un file in? metodo, ma è una riga, quindi spesso lo faccio:

needle.in? haystack
=> exactly the same as above

Se è "più importante" sottolineare il pagliaio, ovvero l'operazione di ricerca, preferisco scrivere include?.Spesso però non ti interessa né il pagliaio né la ricerca, ma solo che l'oggetto sia presente - in questo caso trovo in? trasmette meglio il significato del programma.

Dipende dalle tue esigenze.

Ad esempio, se non ti interessano le proprietà del ricercatore (ad es.forza del ricercatore, visione, ecc.), allora direi che haystack.find(needle) sarebbe la soluzione più pulita.

Ma, se ti interessano le proprietà del ricercatore (o qualsiasi altra proprietà), inserirei un'interfaccia ISearcher nel costruttore del pagliaio o nella funzione per facilitarlo.Ciò supporta sia la progettazione orientata agli oggetti (un pagliaio ha aghi) sia l'inversione del controllo/inserimento delle dipendenze (semplifica il test unitario della funzione "trova").

Mi vengono in mente situazioni in cui uno dei primi due gusti ha senso:

Se l'ago necessita di pre-elaborazione, come nell'algoritmo Knuth-Morris-Pratt, needle.findIn(haystack) (O pattern.findIn(text)) ha senso, perché l'oggetto ago contiene le tabelle intermedie create affinché l'algoritmo funzioni in modo efficace
Se il pagliaio necessita di pre-elaborazione, come ad esempio in un trie, il file haystack.find(needle) (O words.hasAWordWithPrefix(prefix)) funziona meglio.

In entrambi i casi precedenti, uno tra ago o pagliaio è a conoscenza della ricerca.Inoltre, entrambi sono consapevoli l'uno dell'altro.Se vuoi che l'ago e il pagliaio non si accorgano l'uno dell'altro o della ricerca, searcher.find(needle, haystack) sarebbe appropriato.

Facile:Brucia il pagliaio!Successivamente rimarrà solo l'ago.Inoltre, potresti provare i magneti.

Una domanda più difficile:Come trovi un ago particolare in un pool di aghi?

Risposta:infilarli ciascuno e attaccare l'altra estremità di ciascun filo a un indice ordinato (ad es.puntatori)

La risposta a questa domanda dovrebbe in realtà dipendere dal dominio per cui è implementata la soluzione.
Se ti capita di simulare una perquisizione fisica in un pagliaio fisico, potresti seguire le lezioni

Spazio
Paglia
Ago
Cercatore

Spazio
sa quali oggetti si trovano a quali coordinate
implementa le leggi della natura (converte l'energia, rileva le collisioni, ecc.)

Ago, Paglia
si trovano nello Spazio
reagire alle forze

Cercatore
interagisce con lo spazio:
muove la mano, applica un campo magnetico, brucia il fieno, applica i raggi X, cerca l'ago...

Cosìseeker.find(needle, space) O seeker.find(needle, space, strategy)

Il pagliaio si trova proprio nello spazio in cui stai cercando l'ago.Quando astrai lo spazio come una sorta di macchina virtuale (pensa a:la matrice) potresti ottenere quanto sopra con il pagliaio invece dello spazio (soluzione 3/3b):

seeker.find(needle, haystack) O seeker.find(needle, haystack, strategy)

Ma la matrice era il Dominio, che dovrebbe essere sostituito solo dal pagliaio, se il tuo ago non potesse essere altrove.

E poi ancora, era solo un'anologia.È interessante notare che questo apre la mente a direzioni totalmente nuove:
1.Innanzitutto perché hai perso l'ago?Puoi cambiare il processo, in modo da non perderlo?
2.Devi ritrovare l'ago smarrito o puoi semplicemente prenderne un altro e dimenticarti del primo?(Allora sarebbe bello se l'ago si sciogliesse dopo un po')
3.Se perdi regolarmente gli aghi e hai bisogno di ritrovarli, allora potresti volerlo fare

realizzare aghi in grado di ritrovarsi, ad es.si chiedono regolarmente:Mi sono perso?Se la risposta è sì, inviano la posizione calcolata dal GPS a qualcuno o iniziano a emettere segnali acustici o altro:
needle.find(space) O needle.find(haystack) (soluzione 1)
installa un pagliaio con una telecamera su ogni cannuccia, poi puoi chiedere alla mente dell'alveare del pagliaio se ha visto l'ago ultimamente:
pagliaio.trova(ago) (soluzione 2)
attacca i tag RFID ai tuoi aghi, in modo da poterli triangolare facilmente

Tutto questo solo per dirlo nella tua implementazione Voi ha creato l'ago e il pagliaio e il più delle volte la matrice a un certo livello.

Quindi decidi in base al tuo dominio:

Lo scopo del pagliaio è quello di contenere gli aghi?Quindi scegli la soluzione 2.
È naturale che l'ago si perda ovunque?Quindi vai alla soluzione 1.
L'ago si perde per sbaglio nel pagliaio?Quindi scegli la soluzione 3.(o considera un'altra strategia di recupero)

haystack.find(needle), ma dovrebbe esserci un campo di ricerca.

So che l'iniezione di dipendenza è di gran moda, quindi non mi sorprende che haystack.find(needle, searcher) di @Mike Stone sia stato accettato.Ma non sono d'accordo:la scelta di quale ricercatore utilizzare mi sembra una decisione per il pagliaio.

Considera due ISearcher:MagneticSearcher esegue un'iterazione sul volume, spostando e facendo avanzare il magnete in modo coerente con la forza del magnete.QuickSortSearcher divide la pila in due finché l'ago non è evidente in una delle sottopile.La scelta corretta del ricercatore può dipendere da quanto è grande il pagliaio (rispetto al campo magnetico, per esempio), da come l'ago è finito nel pagliaio (cioè, la posizione dell'ago è veramente casuale o è distorta?), ecc.

Se hai Haystack.find (ago, ricercatore), stai dicendo "la cui scelta è la migliore strategia di ricerca è meglio eseguita al di fuori del contesto di Haystack". Non penso che sia probabile che sia corretto.Penso che sia più probabile che "Haystacks sappiano come cercare al meglio". Aggiungi un setter e puoi comunque iniettare manualmente il ricercatore se è necessario sovrascrivere o per il test.

Personalmente mi piace il secondo metodo.Il mio ragionamento è perché le principali API con cui ho lavorato utilizzano questo approccio e trovo che abbia più senso.

Se hai un elenco di cose (pagliaio) dovresti cercare (trova()) l'ago.

@Pietro Meyer

Hai capito.Penso che andare il più liberamente possibile sia una buona cosa, ma forse mi stavo lasciando prendere la mano!:)

Errr...Sì...Penso che la IStuffSmallEnoughToBeLostInAHaystack è una specie di bandiera rossa :-)

Hai anche una quarta alternativa che penso sarebbe migliore dell'alternativa 3:
haystack.find(needle, searcher)

Capisco il tuo punto, ma cosa succederebbe se? searcher implementa un'interfaccia di ricerca che consente di cercare altri tipi di oggetti oltre ai pagliai e di trovare al loro interno altre cose oltre agli aghi?

L'interfaccia potrebbe essere implementata anche con algoritmi diversi, ad esempio:

binary_searcher.find(needle, haystack)
vision_searcher.find(pitchfork, haystack)
brute_force_searcher.find(money, wallet)

Ma, come altri hanno già sottolineato, penso anche che questo sia utile solo se effettivamente disponi di più algoritmi di ricerca o più classi ricercabili o trovabili.In caso contrario, sono d'accordo haystack.find(needle) è migliore per la sua semplicità, quindi sono disposto a sacrificare un po' di "correttezza" per esso.

class Haystack {//whatever
 };
class Needle {//whatever
 }:
class Searcher {
   virtual void find() = 0;
};

class HaystackSearcher::public Searcher {
public:
   HaystackSearcher(Haystack, object)
   virtual void find();
};

Haystack H;
Needle N;
HaystackSearcher HS(H, N);
HS.find();

Un mix di 2 e 3, davvero.

Alcuni pagliai non hanno una strategia di ricerca specializzata;un esempio di ciò è un array.L'unico modo per trovare qualcosa è iniziare dall'inizio e testare ogni elemento finché non trovi quello che desideri.

Per questo genere di cose, una funzione gratuita è probabilmente la migliore (come C++).

Ad alcuni pagliai può essere imposta una strategia di ricerca specializzata.È possibile ordinare un array, consentendo ad esempio di utilizzare la ricerca binaria.Una funzione libera (o una coppia di funzioni libere, ad es.sort e Binary_search) è probabilmente l'opzione migliore.

Alcuni pagliai hanno una strategia di ricerca integrata come parte della loro implementazione;i contenitori associativi (insiemi e mappe con hash o ordinati) lo fanno tutti, ad esempio.In questo caso, trovare è probabilmente un metodo di ricerca essenziale, quindi probabilmente dovrebbe essere un metodo, ad es.pagliaio.trova(ago).

Haystack può contenere cose che un tipo di roba è l'ago che il cercatore è qualcosa che è responsabile della ricerca di cose che cercano può accettare un mucchio di cose come fonte di dove trovare cose che cercano può anche accettare una descrizione di cose che deve trovare

quindi, preferibilmente, per una soluzione flessibile faresti qualcosa del tipo:Interfaccia IStuff

Haystack = ilistu003CIStuff> Ago :Roba

Finder .find (istuff stuffookfor, ilistu003CIStuff> StuckStolookin)

In questo caso, la tua soluzione non sarà legata solo ad ago e pagliaio ma è utilizzabile per qualsiasi tipo che implementi l'interfaccia

quindi se vuoi trovare un pesce nell'oceano, puoi farlo.

var risultati = Finder.Find(pesce, oceano)

Se hai un riferimento all'oggetto ago perché lo cerchi?:) Il dominio del problema e i casi d'uso ti dicono che non hai bisogno di una posizione esatta di ago in un pagliaio (come quello che potresti ottenere da elenco.indexof (elemento)), hai solo bisogno di un ago.E non ce l'hai ancora.Quindi la mia risposta è qualcosa del genere

Needle needle = (Needle)haystack.searchByName("needle");

Needle needle = (Needle)haystack.searchWithFilter(new Filter(){
    public boolean isWhatYouNeed(Object obj)
    {
        return obj instanceof Needle;
    }
});

Needle needle = (Needle)haystack.searchByPattern(Size.SMALL, 
                                                 Sharpness.SHARP, 
                                                 Material.METAL);

Sono d'accordo che ci siano più soluzioni possibili basate su diverse strategie di ricerca, quindi introducono searcher.Ci sono stati abbastanza commenti su questo, quindi non ci presterò attenzione qui.Il mio punto è che le soluzioni di cui sopra dimenticano i casi d'uso: che senso ha cercare qualcosa se hai già un riferimento ad esso?Nel caso d'uso più naturale non hai ancora un ago, quindi non usi l'ago variabile.

Brad Wilson sottolinea che gli oggetti dovrebbero avere un'unica responsabilità.Nel caso estremo, un oggetto ha una responsabilità e nessuno stato.Allora può diventare...una funzione.

needle = findNeedleIn(haystack);

Oppure potresti scriverlo così:

SynchronizedHaystackSearcherProxyFactory proxyFactory =
    SynchronizedHaystackSearcherProxyFactory.getInstance();
StrategyBasedHaystackSearcher searcher =
    new BasicStrategyBasedHaystackSearcher(
        NeedleSeekingStrategies.getMethodicalInstance());
SynchronizedHaystackSearcherProxy proxy =
    proxyFactory.createSynchronizedHaystackSearcherProxy(searcher);
SearchableHaystackAdapter searchableHaystack =
    new SearchableHaystackAdapter(haystack);
FindableSearchResultObject foundObject = null;
while (!HaystackSearcherUtil.isNeedleObject(foundObject)) {
    try {
        foundObject = proxy.find(searchableHaystack);
    } catch (GruesomeInjuryException exc) {
        returnPitchforkToShed();  // sigh, i hate it when this happens
        HaystackSearcherUtil.cleanUp(hay); // XXX fixme not really thread-safe,
                                           // but we can't just leave this mess
        HaystackSearcherUtil.cleanup(exc.getGruesomeMess()); // bug 510000884
        throw exc; // caller will catch this and get us to a hospital,
                   // if it's not already too late
    }
}
return (Needle) BarnyardObjectProtocolUtil.createSynchronizedFindableSearchResultObjectProxyAdapterUnwrapperForToolInterfaceName(SimpleToolInterfaces.NEEDLE_INTERFACE_NAME).adapt(foundObject.getAdaptable());

Il pagliaio non dovrebbe sapere dell'ago e l'ago non dovrebbe sapere del pagliaio.Chi ricerca deve conoscerli entrambi, ma il vero punto in discussione è se il pagliaio debba o meno sapere come cercare da solo.

Quindi opterei per un mix di 2 e 3;il pagliaio dovrebbe essere in grado di dire a qualcun altro come cercarlo e chi effettua la ricerca dovrebbe essere in grado di utilizzare tali informazioni per cercare nel pagliaio.

haystack.magnet().filter(needle);

Il codice sta cercando di trovare un ago specifico o semplicemente un ago qualsiasi?Sembra una domanda stupida, ma cambia il problema.

Cercando un ago specifico, il codice nella domanda ha senso.Cercare un ago sarebbe più simile

needle = haystack.findNeedle()

needle = searcher.findNeedle(haystack)

In ogni caso, preferisco avere un ricercatore in quella classe.Un pagliaio non sa cercare.Dal punto di vista CS è solo un archivio dati con MOLTE schifezze che non vuoi.

Sicuramente il terzo, IMHO.

La questione di un ago in un pagliaio è un esempio di un tentativo di trovare un oggetto in una vasta raccolta di altri, il che indica che avrà bisogno di un algoritmo di ricerca complesso (che potrebbe coinvolgere magneti o (più probabilmente) processi figli) e non lo fa. Non ha molto senso aspettarsi che un pagliaio si occupi della gestione dei thread o dell'implementazione di ricerche complesse.

Un oggetto di ricerca, tuttavia, è dedicato alla ricerca e ci si può aspettare che sappia come gestire i thread secondari per una ricerca binaria veloce o utilizzare le proprietà dell'elemento cercato per restringere l'area (ad esempio:una calamita per trovare oggetti ferrosi).

Un altro modo possibile può essere quello di creare due interfacce per l'oggetto ricercabile, ad es.pagliaio e oggetto ToBeSearched ad es.ago.Quindi, può essere fatto in questo modo

public Interface IToBeSearched
{}

public Interface ISearchable
{

    public void Find(IToBeSearched a);

}

Class Needle Implements IToBeSearched
{}

Class Haystack Implements ISearchable
{

    public void Find(IToBeSearched needle)

   {

   //Here goes the original coding of find function

   }

}

haystack.iterator.findFirst(/* pass here a predicate returning
                               true if its argument is a needle that we want */)

iterator può essere interfaccia con qualsiasi raccolta immutabile, con raccolte che hanno in comune findFirst(fun: T => Boolean) metodo per svolgere il lavoro.Finché il pagliaio è immutabile, non c'è bisogno di nascondere dati utili all'"esterno".E, naturalmente, non è bene collegare insieme l'implementazione di una raccolta personalizzata non banale e alcune altre cose che hanno haystack.Dividi e conquista, ok?

Nella maggior parte dei casi preferisco essere in grado di eseguire semplici operazioni di supporto come questa sull'oggetto principale, ma a seconda del linguaggio, l'oggetto in questione potrebbe non avere a disposizione un metodo sufficiente o sensato.

Anche in lingue come JavaScript) che ti permettono di aumentare/estendere gli oggetti integrati, trovo che possa essere sia conveniente che problematico (ad es.se una versione futura del linguaggio introduce un metodo più efficiente che viene sovrascritto da uno personalizzato).

Questo articolo fa un buon lavoro nel delineare tali scenari.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow