У програмуванні інтерфейс визначає, якою буде поведінка об'єкта, але він фактично не визначає поведінку. Це договір, який гарантує, що певний клас може щось зробити.
Розглянемо цей фрагмент коду C # тут:
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());
Для класу Ігор потрібен секретний номер. Для того, щоб перевірити його, ви хочете ввести те, що буде використовуватися як секретний номер (цей принцип називається Інверсія управління).
Ігровий клас хоче бути «відкритим» щодо того, що насправді створить випадкове число, тому він запитає у своєму конструкторі «все, що має метод Generate».
Спочатку в інтерфейсі вказується, які операції буде надавати об’єкт. Він просто містить те, як він виглядає, але фактичної реалізації не дається. Це лише підпис методу. Зазвичай в інтерфейсах C # встановлено префікс I. Я тепер класи реалізують інтерфейс IGenerate. Це означає, що компілятор переконається, що вони обидва мають метод, який повертає int і викликаєтьсяGenerate . Зараз у грі називають два різних об'єкта, кожен з яких реалізує правильний інтерфейс. Інші класи створюють помилку при побудові коду.
Тут я помітив аналогію креслення, яку ви використовували:
Клас зазвичай розглядається як креслення для об'єкта. Інтерфейс визначає те, що потрібно буде робити класу, тому можна стверджувати, що це дійсно є простою схемою для класу, але оскільки клас не обов'язково потребує інтерфейсу, я б стверджував, що ця метафора порушується. Подумайте про інтерфейс як про контракт. Клас, який "підписує його", буде юридично вимагатися (примусово виконуватись укладачами міліції), відповідати умовам і умовам договору. Це означає, що йому доведеться робити те, що вказано в інтерфейсі.
Все це пов’язано зі статично типовим характером деяких мов OO, як це стосується Java або C #. У Python, з іншого боку, використовується інший механізм:
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
Тут жоден з класів не реалізує інтерфейс. Python з цього приводу не переймається, тому що SecretGameклас просто намагатиметься викликати будь-який об'єкт, переданий. Якщо об'єкт має метод create (), все добре. Якщо це не так: KAPUTT! Ця помилка буде помічена не під час компіляції, а під час виконання, тому, можливо, коли ваша програма вже розгорнута та запущена. C # сповістив би вас, перш ніж ви наблизилися до цього.
Причина, по якій цей механізм використовується, наївно заявлена, оскільки в мовах ОО природно функції не є громадянами першого класу. Як бачите, KnownNumberі SecretNumberмістять ПОСЛУГИ функції для генерації числа. Один насправді взагалі не потребує занять. У Python, отже, можна було просто відкинути їх та вибрати функції самостійно:
# 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)
Лямбда - це лише функція, яка була оголошена "в черзі, як ви йдете". Делегат такий самий у C #:
class Game
{
public Game(Func<int> generate)
{
Console.WriteLine(generate())
}
}
new Game(() => 5);
new Game(() => new Random().Next(0, 10));
Бічна примітка: Останні приклади не були можливі, як, наприклад, до Java 7. Там інтерфейси були вашим єдиним способом конкретизації такої поведінки. Однак Java 8 представила лямбда-вирази, тому приклад C # можна перетворити на Java дуже легко ( Func<int>стає java.util.function.IntSupplierі =>стає ->).