OOP, дизайн интерфейса и инкапсуляция

Question

Проект C#, но он может применяться к любым языкам OO. 3 интерфейсов взаимодействующие:

public interface IPublicData {} 

public /* internal */ interface IInternalDataProducer { string GetData(); } 

public interface IPublicWorker { 
    IPublicData DoWork(); 
    IInternalDataProducer GetInternalProducer(); 
} 

public class Engine { 
    Engine(IPublicWorker worker) {} 
    IPublicData Run() { 
     DoSomethingWith(worker.GetInternalProducer().GetData()); 
     return worker.DoWork(); 
    } 
} 

Ясно Engine параметрический в фактическом работнике, который делает работу. Другим источником параметризации является то, как мы производим «внутренние данные» через IInternalDataProducer. Эта реализация требует, чтобы IInternalDataProducer был общедоступным, поскольку он является частью декларации открытого интерфейса IPublicWorker. Тем не менее, я бы хотел, чтобы он был внутренним, поскольку он используется только движком.

Решение состоит в том, чтобы сделать внутренние данные сами, но это не очень элегантно, так как существует всего несколько способов его создания (в то время как есть много других реализаций рабочих), поэтому приятно делегировать пару отдельные конкретные классы. Кроме того, IInternalDataProducer используется в других местах внутри двигателя, поэтому для двигателя полезно обходить фактический объект.

Также не вариант (очевидно) передать экземпляр IInternalDataProducer непосредственно на конструктор Engine. Мы не хотим, чтобы пользователи библиотеки (Engine) знали о производителе данных. Обязанность работника - объявлять (производить), какой производитель данных следует использовать.

Я ищу элегантный, безопасный тип, идеи/узоры. Приветствие :-)

EDIT: На основании ответа Джеффа, вот решение:

Это не идеально, потому что интерфейс по-прежнему «грязный» с GetData(), которые пользователь не должен видеть (но мой оригинальный интерфейс тоже был грязным), а потому, что он приводит к «дублированию интерфейса» (GetData() объявлен в двух интерфейсах) - у вас не может быть всего.

Следующая проблема заключается в том, чтобы очистить GetData() из интерфейса IPublicWorker тогда :)

public interface IPublicData {} 

internal /* ! */ interface IInternalDataProducer { string GetData(); } 

public interface IPublicWorker { 
    IPublicData DoWork(); 
    string GetData(); 
} 

public class APublicWorker : IPublicWorker { 

    private IInternalDataProducer dataProducer; 

    public APublicWorker() { 
     dataProducer = new SomeDataProducer(); 
    } 

    IPublicData DoWork() { ... } 
    string GetData() { 
     /* Delegation! */ 
     return dataProducer.GetData(); 
     /* ********* */ 
    } 
} 

public class Engine { 
    Engine(IPublicWorker worker) {} 
    IPublicData Run() { 
     DoSomethingWith(worker.GetData()); 
     return worker.DoWork(); 
    } 
} 

Answer 1

Вы можете решить эту проблему путем инкапсуляции производителя данных в рабочий :

public interface IPublicWorker { 
    IPublicData DoWork(); 
    // Callers don't care how a worker gets this data 
    string GetData(); 
} 

звонок в двигателе будет выглядеть следующим образом:

IPublicData Run() { 
    DoSomethingWith(worker.GetData()); 
    return worker.DoWork(); 
} 

Answer 2

Почему бы не определить GetInternalProducer(), как

object GetInternalProducer(); 

и использовать что-то вроде

IInternalDataProducer producer = GetInternalProducer() as IInternalDataProducer. 

вам нужно будет проверить нулевой указатель, но вам не нужно xpose IInternalDataProducer больше.

Таким образом, вы можете предоставить фабрику для создания объектов IInternalProducer внутри Engine и связать их с объектами IPublicWorker или любым другим кодом, находящимся вне приложения. В противном случае клиентский код должен знать о IInternalDataProducer, тем самым нарушая инкапсуляцию Engine.

Answer 3

Edited с учетом требований от комментариев:

public interface IPublicData { } 

public interface IDataProducer { string GetData(); } 

internal interface IInternalDataProducer : IDataProducer { string GetData(); } 

internal class InternalDataProducer : IInternalDataProducer 
{ 
    public string GetData() 
    { 
     throw new NotImplementedException(); 
    } 
} 

public interface IPublicWorker 
{ 
    IPublicData DoWork(); 
    IDataProducer GetInternalProducer(); 
} 

class PublicWorker : IPublicWorker 
{ 
    public IPublicData DoWork() 
    { 
     throw new NotImplementedException(); 
    } 

    public IDataProducer GetInternalProducer() 
    { 
     return new InternalDataProducer(); //here you binds PublicWorker to paricular data provider 
    } 
} 


public class Engine 
{ 
    private IPublicWorker worker; 

    public Engine(IPublicWorker worker) 
    { 
     this.worker = worker; 
    } 

    IPublicData Run() 
    { 
     DoSomethingWith(this.worker.GetInternalProducer()); 
     return worker.DoWork(); 
    } 

    private void DoSomethingWith(IDataProducer getData) 
    { 
     throw new NotImplementedException(); 
    } 
} 

Answer 4

UPDATE
Мое решение не кажется правильным, по крайней мере, это не работает, как я предназначен. Может быть, кто-то другой может заставить его работать, так как это будет наиболее логичное решение (imho).

---

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

public interface IPublicData {} 

public interface IPublicDataProducer {} 
internal interface IInternalDataProducer : IPublicDataProducer { string GetData(); } 

public interface IPublicWorker { 
    IPublicData DoWork(); 
    IPublicDataProducer GetProducer(); 
} 

public class Engine { 
    Engine(IPublicWorker worker) {} 
    IPublicData Run() { 
     DoSomethingWith(worker.GetProducer()); 
     return worker.DoWork(); 
    } 
} 

Это позволяет разделять данные для внешних и внутренних пользователей ваших интерфейсов.

Answer 5

На самом деле решение Олега не так уж плохо, но его можно улучшить.

Учитывая, что вы хотите установить ограничения на интерфейс IPublicWorker, я предполагаю, что вы хотите управлять реализациями IPublicWorker и предоставлять своим пользователям определенный API для их получения. Если это так, то вы могли бы вывести IInternalPublicWorker из IPublicWorker, и в конструкторе двигателя, убедитесь, что IPublicWorker действительно ожидаемого типа:

public interface IPublicData {} 


public internal interface IInternalDataProducer { string GetData(); } 

public interface IPublicWorker { 
    IPublicData DoWork(); 
} 

public internal interface IInternalPublicWorker : IPublicWorker { 
    IInternalDataProducer GetInternalProducer(); 
} 

public class Engine 
{ 
    IInternalPublicWorker _worker; 

    Engine(IPublicWorker worker) 
    { 
     if (!(worker is IInternalPublicWorker)) 
     { 
      throw new InvalidOperationException("We don't support workers that were not obtained from our library."); // add some helpful message about which method to use to obtain a worker 
     } 
     _worker = (IInternalPublicWorker)worker; 
    } 
    IPublicData Run() 
    { 
     DoSomethingWith(_worker.GetInternalProducer().GetData()); 
     return _worker.DoWork(); 
    } 
}