È giusto presupporre che un costruttore sovraccarico per una classe possa essere pensato come un "papero" per la tipizzazione delle anatre? Diciamo che ClassA ha un costruttore sovraccarico, sarebbe ragionevole pensare che i diversi costruttori siano lì per un motivo: l'oggetto viene usato in un modo che indica che tutte le sue proprietà non devono essere impostate per l'oggetto da eseguire correttamente.
Quindi, chiedo, è un costruttore sovraccarico di un'anatra?
Direi che questo è non una forma accettabile di digitazione anatra in un linguaggio statico.
In un linguaggio che supporta la digitazione anatra, ci si aspetterebbe di essere in grado di definire una funzione che accetta un oggetto foo di tipo non specificato che definisce una funzione (o proprietà) bar .
def call_bar (foo) {
foo.bar
}
Alla funzione non interessa il tipo foo , solo che è bar . Il tuo sistema non fornisce alcun modo per una funzione di prendere un oggetto di qualsiasi tipo, purché quel tipo definisca le funzioni richieste.
Bene, l'approccio tipico nella maggior parte delle lingue è definire le interfacce . Questo non ci porta tutti nel modo in cui ci sono, ma ci avvicina. Possiamo almeno definire un contratto con il quale identifichiamo tutte le funzioni / proprietà / etc pertinenti su un tipo.
Una funzione può quindi essere scritta in modo tale da accettare input per interfaccia, piuttosto che classi concrete. Manteniamo la possibilità di controllare il tipo in fase di compilazione, per garantire che le funzioni richieste esistano sugli input, pur ottenendo la flessibilità di ignorare i dettagli di implementazione.
Scala ha un approccio interessante a questo, che offre un modo molto più flessibile per ottenere un comportamento tipizzato da anatra in un linguaggio statico. Scala consente di fare riferimento a un tipo in termini di membri, utilizzando la seguente sintassi:
def callBar(foo : { def bar() : Unit }) = {
foo.bar()
}
Questo corrisponderà a tutti i tipi che definiscono la funzione bar , non accettando input e restituendo output void. Conserva anche i vantaggi statici di tipizzazione di un linguaggio statico, anziché fare affidamento sull'associazione tardiva per determinare se gli input avranno o meno i membri giusti.
No, non lo è.
Gli oggetti di una particolare classe supportano tutti esattamente lo stesso insieme di messaggi, indipendentemente dal costruttore con cui sono stati creati. Sovraccaricare i costruttori significa semplicemente che non è necessario inizializzare esplicitamente tutti i campi che costituiscono lo stato di un oggetto. Ad esempio, un oggetto potrebbe avere un colore con un valore predefinito ragionevole, quindi è possibile avere un costruttore con un valore di colore e uno senza tale valore, mentre un campo che è una chiave esterna obbligatoria a un'altra entità non può essere costituito da la classe, quindi deve sempre essere un argomento costruttore. Ma in Java, tutti i membri della classe sono completamente definiti quando viene costruito un oggetto (infatti, in fase di esecuzione non esiste un valore non definito), quindi non è utile confrontare gli oggetti Java con quelli in lingue dattiloscritte.
È giusto dire che i costruttori sovraccaricati specificano diversi modi di costruire un'anatra. Non è comunque la digitazione anatra.
Considera la seguente classe:
public class Rectangle
{
public Rectangle(Point A, Point B)
{
// Constructs a rectangle by using points A and B as a diagonal,
// and filling in the rectangle with the usual lines at right angles.
}
public Rectangle(Point A, Length diagonal, Angle angle)
{
// Computes Point B using the specified size and diagonal, and then
// calls the first constructor.
}
public Rectangle(Point A, Point B, Point C, Point D)
{
// Constructs a rectangle from the four supplied points, and
// verifies that all angles are 90 degrees.
}
}