В чем разница между опубликованными и общедоступными методами / атрибутами? - PullRequest
1 голос
/ 14 декабря 2008

По словам Мартина Фаулера, «что-то может быть общедоступным, но это не значит, что вы опубликовали это». Означает ли это что-то вроде этого:

public interface IRollsRoyceEngine
{
    void Start();
    void Stop();
    String GenerateEngineReport();
}

public class RollsRoyceEngine : IRollsRoyceEngine
{
    public bool EngineHasStarted { get; internal set; }

    public bool EngineIsServiceable { get; internal set; }

    #region Implementation of IRollsRoyceEngine

    public void Start()
    {
        if (EngineCanBeStarted())
            EngineHasStarted = true;
        else
            throw new InvalidOperationException("Engine can not be started at this time!");
    }

    public void Stop()
    {
        if (EngineCanBeStopped())
            EngineHasStarted = false;
        else
            throw new InvalidOperationException("Engine can not be started at this time!");
    }

    public string GenerateEngineReport()
    {
        CheckEngineStatus();
        return EngineIsServiceable ? "Engine is fine for now" : "Hmm...there may be some problem with the engine";
    }

    #endregion

    #region Non published methods

    public bool EngineCanBeStarted()
    {
        return EngineIsServiceable ? true : false;
    }

    public bool EngineCanBeStopped()
    {
        return EngineIsServiceable ? true : false;
    }

    public void CheckEngineStatus()
    {
        EngineIsServiceable = true;
        //_EngineStatus = false;
    }

    #endregion

}

Можно ли сказать, что опубликованным интерфейсом является IRollsRoyceEngine, а не то, что есть в RollsRoyceEngine?

Если да, то в чем реальная разница между публичными и опубликованными методами?

Ответы [ 2 ]

5 голосов
/ 14 декабря 2008

Я предполагаю, что он имеет в виду, что контракт является королем - только потому, что метод в вашем классе является общедоступным, не дает клиентам права предполагать, что они могут вызвать его, или что они знают, что он делает, или что он будет там в следующей версии. API не определяются источником, они определяются контрактом, обычно в форме документации.

Ответственность за то, чтобы не вызывать недокументированные (неопубликованные) функции, лежит на клиенте, а исполнитель не должен скрывать методы, которые не должны вызываться.

Некоторые люди могут не согласиться с этим - как правило, те, кто не доверяет документации, и предпочитают узнать, как все работает, посмотрев на источник, чтобы увидеть, что на самом деле делает , а не то, что автор утверждает, что это делает. Они вполне могут иметь смысл, особенно на практике при работе с недокументированным кодом. Но я думаю, что это противоречит тому, что говорит Фаулер, о том, что функциональность должна быть формально определена, а не выведена из рассмотрения конкретной реализации.

2 голосов
/ 14 декабря 2008

По моему мнению, упомянутый технический документ говорит о целевой аудитории API, а не о различии интерфейса и его реализации.

Вы можете найти аналогию в Руководстве по проектированию фреймворка , в котором говорится, что после поставки API у вас есть контракт с потребителями. Например, если вы поставили в v1 вашего интегрированного интерфейса IService, вы не сможете изменить его в v2, потому что это приведет к серьезным изменениям для конечных разработчиков. Вместо этого вы должны создать новый интерфейс IService2, унаследованный от IService, и отправить его с версией v2.

Таким образом, общедоступный API публикуется, как только вы «заключаете договор» с конечными разработчиками.

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

Надеюсь, это объяснение поможет.

...