What is the difference between published and publicly available methods / attributes?

In the words of Martin Fowler, "Something may be public, but that doesn't mean you published it." Does it mean something like this:

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

}

      

Would you say that the posted interface of this IRollsRoyceEngine doesn't work in RollsRoyceEngine?

If so, what is the real difference between public and published methods?

+1


source to share


2 answers


In my opinion, the white article mentioned is talking about the target audience of the API, not the difference between an interface and its implementation.

You can find an analogy in the Framework Design Guidelines , which says that once your API is shipped, you have a contract with consumers. For example, if you have submitted to v1 the IService interface interface, you will not be able to change it in version 2, because it will make changes to the developer ending. Instead, you have to create a new IService2 interface installed in IService and submit it using v2.

Thus, the public API will be published after you "sign the contract" with the end developers.



Coming back to your code - it will be published when you submit it to the developer community for example.

Hope this explanation helps.

+2


source


I assume it means the contract is king - just because the method in your class is public prevents clients from assuming they can call it, or that they know what it does, or that it will be there next version. APIs are not source specific, they are contract specific, usually in the form of documentation.

It is the client's responsibility not to call undocumented (unpublished) functions, and not the developer's responsibility to hide methods that should not be called.



Some people may disagree with this - usually those who don't trust the documentation and are more likely to find out how things work by looking at the source to see what it actually does, rather than what the author claims to be it does. They may very well have a point, especially in practice when it comes to underappreciated code. But I think, contrary to what Fowler says, is that functionality should be formally defined, not inferred by examining a specific implementation.

+5


source







All Articles