How do I hide a method so it's not called by programmers but still usable in code?

Question

I have a class called 'Ship' and a class called 'Lifeboat'

Lifeboat inherits from Ship.

Ship contains a method called Validate() which is called before save and it has an abstract method called FurtherValidate() which it calls from Validate. The reason this is in place is so when you call validate on the base it also validates the class that is inheriting. So we have

public class Ship

public bool Validate()
{
//validate properties only found on a ship

FurtherValidate();
}

public abstract bool FurtherValidate();

So Lifeboat has

public override bool FurtherValidate()
{
//validate properties only found on a lifeboat
}

This means anyone implementing Ship also needs to provide there own validation for there class and it's guaranteed to be called on the save as the base ship.Validate() is called which in turns calls the inherited validate.

How can we re work this so we still force inherited classes to implement FurtherValidate() but FurtherValidate() can never be called by the programmer. Currently you can called Lifeboat.FurtherValidate and I want to somehow prevent this.

Thanks

Answer 1

Making it protected instead of public will at least prevent outside objects from calling it.

Answer 2

protected abstract bool FurtherValidate();

only Ship and Lifeboat can see it now.

EDIT: Lifeboat must be able to see it. How should it be able to override FurtherValidate when it can't even see it. I would rename it to ValidateCore, the 'Core' part (to me) implies that it should not be called without a very good reason.

I don't think it's easy to make it abstract but not visible. You need to have some faith in your lifeboat ;)

Answer 3

You could mark the method as protected so only inheriting classes can access it. This does not prevent inheritors from exposing the method through another public method but that's usually not a major concern.

Answer 4

The most simple answer would be to make the method protected. This allows the inheritors to call it but does not make it publicly available. However there is nothing to stop the inheriting classes changing the method to public.

I would be more inclined to remove the FurtherValidate method entirely and have any inheriting classes override Validate, calling base.Validate() if they wish. This allows any class that inherits from ship to have a greater degree of control over the validate method.

Answer 5

Probably you could try the private modifier

Answer 6

Short answer is, you can't hide the derived method from the class that's deriving it. However, you can refactor your code to accomplish what you're trying to achieve:

public class Ship
{    
    public virtual bool Validate()    
    {        
        //validate properties only found on a ship
        return true;
    }
}
public class Lifeboat : Ship
{   
    public override bool Validate()   
    {       
        base.Validate();       
        // lifeboat specific code
        return true;
    }
}

Answer 7

protected is the correct approach here. But in another situation, you may wish to use editorbrowsableattribute which will hide the method from intellisense. You can still call it, but it slows down devs from calling something that could blow up the program, and will usually force them to read your giant comment-warnings.

Answer 8

The exact scenario you describe isn't possible. You can restrict access to the FurtherValidate method to only derived classes by using the protected access modifier. You could also restrict it to only classes in the same assembly by using the internal modifier, but this would still allow the programmer writing the derived class to call FurtherValidate any time they wish. Using both protected and internal combines the two and really means that is restricted to derived classes or classes defined in the same assembly.

Using the [EditorBrowsable] attribute is an IDE trick that will hide the method from IntelliSense (unless the other programmer has turned on the right options in VS). That will effectively prevent most people from calling it (if they can't see it, it doesn't exist).

You could possibly achieve this using reflection to interrogate who your caller is, but I think the performance costs of doing this would be too high compared to the benefit.

Answer 9

I see a code smell here, since Validate isn't part of the functional responsibility of a ship. In other words, I think maybe you're trying to solve a problem using inheritance when maybe that's not the best solution. Try refactoring your validation logic so that you inject your validation in to the class. This will make better sense in terms of a domain object Ship, since ships don't validate themselves, they're validated externally. If you want to enforce that there must be a validator, then you can throw an exception if the property is null.

protected IValidator FurtherValidation { private get; set; }

public bool Validate()
{
//validate properties only found on a ship

    if (FurtherValidation == null)
        throw new ValidationIsRequiredException();
    if (!FurtherValidation.IsValid(this))
        // logic for invalid state
}