Trong Lập trình, một giao diện xác định hành vi mà một đối tượng sẽ có, nhưng nó sẽ không thực sự chỉ định hành vi. Đó là một hợp đồng, điều đó sẽ đảm bảo, rằng một lớp nào đó có thể làm được điều gì đó.
Hãy xem xét đoạn mã C # này ở đây:
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());
Lớp Trò chơi yêu cầu một số bí mật. Để kiểm tra nó, bạn muốn đưa những gì sẽ được sử dụng làm số bí mật (nguyên tắc này được gọi là Inversion of Control).
Lớp trò chơi muốn "cởi mở" về những gì sẽ thực sự tạo ra số ngẫu nhiên, do đó nó sẽ hỏi trong hàm tạo của nó "bất kỳ thứ gì có phương thức Tạo".
Đầu tiên, giao diện chỉ định những hoạt động mà một đối tượng sẽ cung cấp. Nó chỉ chứa những gì nó trông như thế nào, nhưng không có triển khai thực tế nào được đưa ra. Đây chỉ là chữ ký của phương thức. Thông thường, trong các giao diện C # được bắt đầu bằng chữ I. Các lớp hiện triển khai Giao diện IGenerate. Điều này có nghĩa là trình biên dịch sẽ đảm bảo rằng cả hai đều có một phương thức, trả về một int và được gọi Generate. Trò chơi hiện đang được gọi là hai đối tượng khác nhau, mỗi đối tượng trong số đó có giao diện chính xác. Các lớp khác sẽ tạo ra lỗi khi xây dựng mã.
Ở đây tôi nhận thấy sự tương tự về kế hoạch chi tiết mà bạn đã sử dụng:
Một lớp thường được coi là bản thiết kế cho một đối tượng. Giao diện chỉ định một cái gì đó mà một lớp sẽ cần phải làm, vì vậy người ta có thể tranh luận rằng nó thực sự chỉ là một bản thiết kế cho một lớp, nhưng vì một lớp không nhất thiết cần một giao diện, tôi sẽ tranh luận rằng phép ẩn dụ này đang phá vỡ. Hãy nghĩ về một giao diện như một hợp đồng. Lớp "ký tên vào nó" sẽ được yêu cầu hợp pháp (được thực thi bởi cảnh sát biên dịch), tuân thủ các điều khoản và điều kiện trong hợp đồng. Điều này có nghĩa là nó sẽ phải làm, những gì được chỉ định trong giao diện.
Tất cả là do bản chất được nhập tĩnh của một số ngôn ngữ OO, như trường hợp của Java hoặc C #. Mặt khác, trong Python, một cơ chế khác được sử dụng:
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
Ở đây, không có lớp nào triển khai giao diện. Python không quan tâm đến điều đó, bởi vì SecretGamelớp sẽ chỉ cố gắng gọi bất kỳ đối tượng nào được truyền vào. Nếu đối tượng CÓ phương thức create (), mọi thứ đều ổn. Nếu không: KAPUTT! Lỗi này sẽ không được nhìn thấy trong thời gian biên dịch, nhưng trong thời gian chạy, vì vậy có thể khi chương trình của bạn đã được triển khai và chạy. C # sẽ thông báo cho bạn trước khi bạn đến gần điều đó.
Lý do cơ chế này được sử dụng, nói một cách ngây thơ, bởi vì trong các ngôn ngữ OO, các chức năng tự nhiên không phải là công dân hạng nhất. Như bạn có thể thấy, KnownNumbervà chỉ SecretNumberchứa các hàm để tạo ra một số. Người ta không thực sự cần các lớp học. Do đó, trong Python, người ta có thể vứt bỏ chúng và tự chọn các hàm:
# 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)
Một lambda chỉ là một hàm, được khai báo "thẳng hàng, khi bạn di chuyển". Một ủy nhiệm giống nhau trong C #:
class Game
{
public Game(Func<int> generate)
{
Console.WriteLine(generate())
}
}
new Game(() => 5);
new Game(() => new Random().Next(0, 10));
Lưu ý: Các ví dụ sau không thể thực hiện như thế này đối với Java 7. Ở đó, Giao diện là cách duy nhất của bạn để xác định hành vi này. Tuy nhiên, Java 8 đã giới thiệu các biểu thức lambda nên ví dụ C # có thể được chuyển đổi sang Java rất dễ dàng ( Func<int>trở thành java.util.function.IntSuppliervà =>trở thành ->).