Dalam Pemrograman, antarmuka menentukan perilaku apa yang akan dimiliki suatu objek, tetapi tidak akan benar-benar menentukan perilaku. Ini adalah kontrak, yang akan menjamin, bahwa kelas tertentu dapat melakukan sesuatu.
Pertimbangkan potongan kode C # ini di sini:
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());
Kelas Game membutuhkan nomor rahasia. Untuk mengujinya, Anda ingin memasukkan apa yang akan digunakan sebagai nomor rahasia (prinsip ini disebut Inversion of Control).
Kelas game ingin menjadi "berpikiran terbuka" tentang apa yang sebenarnya akan membuat bilangan acak, oleh karena itu ia akan menanyakan "apa saja, yang memiliki metode Hasilkan" dalam konstruktornya.
Pertama, antarmuka menentukan, operasi apa yang akan disediakan objek. Ini hanya berisi seperti apa tampilannya, tetapi tidak ada implementasi aktual yang diberikan. Ini hanyalah tanda tangan dari metode tersebut. Biasanya, di C # antarmuka diawali dengan I. Kelas sekarang mengimplementasikan Antarmuka IGenerate. Ini berarti kompilator akan memastikan, bahwa mereka berdua memiliki metode, yang mengembalikan sebuah int dan dipanggil Generate. Permainan sekarang disebut dua objek yang berbeda, yang masing-masing mengimplementasikan antarmuka yang benar. Kelas lain akan menghasilkan kesalahan saat membangun kode.
Di sini saya melihat analogi cetak biru yang Anda gunakan:
Kelas biasanya dilihat sebagai cetak biru untuk suatu objek. Antarmuka menentukan sesuatu yang perlu dilakukan oleh kelas, sehingga orang dapat berargumen bahwa itu memang hanya cetak biru untuk kelas, tetapi karena kelas tidak selalu membutuhkan antarmuka, saya berpendapat bahwa metafora ini melanggar. Pikirkan antarmuka sebagai kontrak. Kelas yang "menandatanganinya" akan diwajibkan secara hukum (diberlakukan oleh polisi penyusun), untuk mematuhi syarat dan ketentuan dalam kontrak. Ini berarti bahwa itu harus dilakukan, apa yang ditentukan dalam antarmuka.
Ini semua karena sifat tipe statis dari beberapa bahasa OO, seperti halnya dengan Java atau C #. Di Python, mekanisme lain digunakan:
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
Di sini, tidak ada kelas yang mengimplementasikan antarmuka. Python tidak peduli tentang itu, karena SecretGamekelas hanya akan mencoba memanggil objek apa pun yang dilewatkan. Jika objek MEMILIKI metode generate (), semuanya baik-baik saja. Jika tidak: KAPUTT! Kesalahan ini tidak akan terlihat pada waktu kompilasi, tetapi pada waktu proses, jadi mungkin saat program Anda sudah diterapkan dan dijalankan. C # akan memberi tahu Anda jauh sebelum Anda mendekati itu.
Alasan mekanisme ini digunakan, dinyatakan secara naif, karena dalam bahasa OO secara alami berfungsi bukan warga negara kelas satu. Seperti yang Anda lihat, KnownNumberdan SecretNumberberisi HANYA fungsi untuk menghasilkan angka. Seseorang tidak benar-benar membutuhkan kelas sama sekali. Dengan Python, oleh karena itu, seseorang bisa membuangnya dan memilih fungsinya sendiri:
# 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)
Lambda hanyalah sebuah fungsi, yang dideklarasikan "sejalan, saat Anda pergi". Delegasi sama saja di C #:
class Game
{
public Game(Func<int> generate)
{
Console.WriteLine(generate())
}
}
new Game(() => 5);
new Game(() => new Random().Next(0, 10));
Catatan tambahan: Contoh terakhir tidak mungkin seperti ini hingga Java 7. Di sana, Antarmuka adalah satu-satunya cara Anda untuk menentukan perilaku ini. Namun, Java 8 memperkenalkan ekspresi lambda sehingga contoh C # dapat dikonversi ke Java dengan sangat mudah ( Func<int>menjadi java.util.function.IntSupplierdan =>menjadi ->).