Nella programmazione, un'interfaccia definisce quale sarà il comportamento di un oggetto, ma non specificherà effettivamente il comportamento. È un contratto, che garantirà che una certa classe possa fare qualcosa.
Considera questo pezzo di codice C # qui:
using System;
public interface IGenerate
{
int Generate();
}
// Dependencies
public class KnownNumber : IGenerate
{
public int Generate()
{
return 5;
}
}
public class SecretNumber : IGenerate
{
public int Generate()
{
return new Random().Next(0, 10);
}
}
// What you care about
class Game
{
public Game(IGenerate generator)
{
Console.WriteLine(generator.Generate())
}
}
new Game(new SecretNumber());
new Game(new KnownNumber());
La classe Game richiede un numero segreto. Per motivi di test, si desidera iniettare quello che verrà utilizzato come numero segreto (questo principio è chiamato inversione di controllo).
La classe del gioco vuole essere "di mentalità aperta" su cosa creerà effettivamente il numero casuale, quindi chiederà al suo costruttore "qualsiasi cosa, che abbia un metodo Generate".
Innanzitutto, l'interfaccia specifica quali operazioni fornirà un oggetto. Contiene solo ciò che sembra, ma non viene fornita alcuna implementazione effettiva. Questa è solo la firma del metodo. Convenzionalmente, in C # le interfacce hanno il prefisso I. Le classi ora implementano l'interfaccia IGenerate. Ciò significa che il compilatore si assicurerà che entrambi abbiano un metodo, che restituisca un int e venga chiamato Generate. Il gioco ora viene chiamato due oggetti diversi, ognuno dei quali implementa l'interfaccia corretta. Altre classi produrranno un errore durante la creazione del codice.
Qui ho notato l'analogia del progetto che hai usato:
Una classe è comunemente vista come un modello per un oggetto. Un'interfaccia specifica qualcosa che una classe dovrà fare, quindi si potrebbe sostenere che in realtà è solo un progetto per una classe, ma poiché una classe non ha necessariamente bisogno di un'interfaccia, direi che questa metafora si sta interrompendo. Pensa a un'interfaccia come a un contratto. La classe che "lo firma" sarà obbligata per legge (fatta rispettare dalla polizia del compilatore), per rispettare i termini e le condizioni del contratto. Ciò significa che dovrà fare ciò che è specificato nell'interfaccia.
Tutto ciò è dovuto alla natura tipizzata staticamente di alcuni linguaggi OO, come nel caso di Java o C #. In Python, invece, viene utilizzato un altro meccanismo:
import random
# Dependencies
class KnownNumber(object):
def generate(self):
return 5
class SecretNumber(object):
def generate(self):
return random.randint(0,10)
# What you care about
class SecretGame(object):
def __init__(self, number_generator):
number = number_generator.generate()
print number
In questo caso, nessuna delle classi implementa un'interfaccia. Python non si preoccupa di questo, perché la SecretGameclasse proverà semplicemente a chiamare qualunque oggetto sia passato. Se l'oggetto HA un metodo generate (), va tutto bene. In caso contrario: KAPUTT! Questo errore non verrà visualizzato in fase di compilazione, ma in fase di esecuzione, quindi probabilmente quando il programma è già distribuito e in esecuzione. C # ti avviserebbe molto prima che tu ti avvicini a questo.
Il motivo per cui viene utilizzato questo meccanismo, dichiarato ingenuamente, perché nei linguaggi OO le funzioni naturalmente non sono cittadini di prima classe. Come puoi vedere, KnownNumbere SecretNumbercontengono SOLO le funzioni per generare un numero. Non si ha davvero bisogno delle lezioni. In Python, quindi, si potrebbe semplicemente buttarli via e scegliere le funzioni da soli:
# OO Approach
SecretGame(SecretNumber())
SecretGame(KnownNumber())
# Functional Approach
# Dependencies
class SecretGame(object):
def __init__(self, generate):
number = generate()
print number
SecretGame(lambda: random.randint(0,10))
SecretGame(lambda: 5)
Un lambda è solo una funzione, che è stata dichiarata "in linea, mentre procedi". Un delegato è esattamente lo stesso in C #:
class Game
{
public Game(Func<int> generate)
{
Console.WriteLine(generate())
}
}
new Game(() => 5);
new Game(() => new Random().Next(0, 10));
Nota a margine: gli ultimi esempi non erano possibili come questo fino a Java 7. Là, le interfacce erano l'unico modo per specificare questo comportamento. Tuttavia, Java 8 ha introdotto espressioni lambda in modo che l'esempio C # possa essere convertito in Java molto facilmente ( Func<int>diventa java.util.function.IntSuppliere =>diventa ->).