Скрыть унаследованный член в клиентском проекте

Question

У меня есть интерфейс с методом Validate() и абстрактный класс, который реализует этот интерфейс, и создал класс с именем CustomerValidator, который наследует абстрактный класс, также имеет сущность Customer, наследующую CustomerValidator, поэтому я могу вызватьcustomer.Validate() в проекте библиотеки.

Мой сценарий состоит в том, что я не хочу, чтобы метод validate был доступен в клиентском коде ... если они создают нового клиента, они должны видеть только свойства объекта ... например, имя кулачка и т. Д.Как скрыть метод проверки?Спасибо

Answer 1

Вместо наследования используйте композицию.

Почему ваш Customer класс наследуется от CustomerValidator? Это не a CustomerValidator, не так ли?

Вы можете иметь личное поле CustomerValidator в своем классе Customer - вы можете позвонить Validate на него.

Мой пример на C #, хотя этот принцип применим к Java и другим языкам ООП:

// I would use DI of some sort to decouple the classes. This is just illustative
private CustomerValidator cv = new CustomerValidator(); 

// Somewhere else in the customer class:
cv.Validate(this);

Answer 2

Я знаю, что Customer не является CustomerValidator. Возможно, это имя немного сбивает с толку, но в моем случае у меня есть Customer, реализующий CustomerValidator, в котором в конструктор добавляются правила проверки, и класс Customer остается чистым. Но я нашел ответ на свой вопрос, поэтому я реализовал Интерфейс, где метод validate явно. Поэтому на клиентском коде validate не отображается в сущности Customer.

Answer 3

Я также должен спросить, почему Customer наследует CustomerValidator, но также и почему CustomerValidator абстрактный?Я бы предложил вам изменить интерфейс и реализацию следующим образом:

public interface ICustomerValidator {
    void Validate(Customer customer);
}

public abstract class CustomerValidator : ICustomerValidator {
    public abstract void Validate(Customer customer);
}

Затем, если вы настаиваете на возможности сделать что-то вроде

Customer customer = new Customer();
customer.Validate();

, я бы предложил вам использовать Методы расширения C # , например:

public static class CustomerExentions {
    public static ICustomerValidator CustomerValidator { get; set; }

    internal static void Validate(this Customer c) {
        if(CustomerValidator == null) {
            throw new InvalidOperationException("CustomerValidator cannot be NULL");
        }

        CustomerValidator.Validate(c);
    }
}

Обратите внимание на область действия internal, чтобы клиенты не могли использовать этот вызов.

Что касается использования композиции, я не думаю, Customer должен знать что-нибудь о CustomerValidator или ICustomerValidator.Эти внешние обязанности выходят за рамки Customer класса.Во всяком случае, CustomerValidator может иметь свойство Customer, если вы настаиваете на использовании композиции, но я думаю, что интерфейс должен принимать вместо него параметр Customer.

Answer 4

Я могу придумать немного другой способ организации ваших занятий. Часть, о которой клиент хочет знать (класс «клиент»), содержит все видимые свойства. Внутри вашей библиотеки вы используете классы-оболочки, которые включают сущность customer. Таким образом, ваш librabry работает с полным набором методов, используя классы-обертки, которые включают класс customer, но имеют больше методов, и клиент передает класс costumer в вашу lib, который переносит его перед продолжением.