2013-04-13 4 views
0

Может кто-нибудь объяснить, почему ответ в this question защищает использование методов расширения при определении базовых интерфейсов. - Почему бы не включить методы SteerLeft() и Stop() в соответствующие интерфейсы? - Является ли это иллюстрацией добавления поведения, которое не должно/не может быть ожидаемым/принудительным «базой»? - Не лучше ли «заставить» что-то основное, как «рулевое» поведение, когда вам нужно рулевое колесо?Зачем использовать методы расширения, если вы можете сделать обычный метод?

Ниже я получил соответствующий код. Ответив человек заявляет:

вы можете использовать методы расширения функциональности в C# 3.0 для дальнейшего упрощения вызова методов этих подразумеваемые свойств

public interface ISteerable { SteeringWheel wheel { get; set; } } 

public interface IBrakable { BrakePedal brake { get; set; } } 

public class Vehicle : ISteerable, IBrakable 
{ 
    public SteeringWheel wheel { get; set; } 

    public BrakePedal brake { get; set; } 

    public Vehicle() { wheel = new SteeringWheel(); brake = new BrakePedal(); } 
} 

public static class SteeringExtensions 
{ 
    public static void SteerLeft(this ISteerable vehicle) 
    { 
     vehicle.wheel.SteerLeft(); 
    } 
} 

public static class BrakeExtensions 
{ 
    public static void Stop(this IBrakable vehicle) 
    { 
     vehicle.brake.ApplyUntilStop(); 
    } 
} 


public class Main 
{ 
    Vehicle myCar = new Vehicle(); 
    public void main() 
    { 
    myCar.SteerLeft(); 
    myCar.Stop(); 
    } 
} 
+1

В этом случае это полезно, если у вас много «ISteerables», и вы не хотите копировать-вставлять те же самые тела метода во все из них. –

+1

Если у вас есть вопрос об этом конкретном ответе, тогда почему бы не спросить человека, написавшего ответ *? –

+0

@EricLippert - потому что исходная тема была на другом предмете. Мой интерес представляет собой образовательный, в более широком (а не множественном наследовании) смысл. И пример кода, в сочетании с комментариями, намекает на предмет, отличный от множественного наследования. –

ответ

1

EM не являются заменой множественного наследования, а не является механизмом наследования. Это всего лишь инструмент, например, название, до . Расширьте функциональность какого-либо типа на ваших средствах.

В этом бетон код нет смысла использовать EM. Как вы отметили, вы можете легко расширить функциональность класса, просто добавив новый метод внутри своего тела.

EM чрезвычайно полезны в тех случаях, когда вы не можете изменить исходный код класса или не допускать этого.

+0

Подобно функциональности ядра, например. 'IEnumerable ' – Romoku

4

точка с использованием метода расширения является то, что вам может добавить method в существующий класс .Net, даже если у вас нет Source code или его reside within different assembly.

и расширение метод помогает

  1. Эти методы могут быть добавлены позже (чем время авторинга типа) после того, как тип уже опубликован.
  2. Методы расширения могут ориентироваться на интерфейсы.
  3. Различные люди могут распространять один и тот же тип по-разному в соответствии с их потребностями.

Возьмите LINQ, например, он предоставляет методы, которые работают на любом IEnumerable типа!

+0

Технически метод расширения не добавляет к классу; Он добавляет к типу. –

+0

Вы заявляете что-то очевидное, но не объясняете заявление, которое я повторно опубликовал, и мои вопросы. –