CODEWITHSUNDEEP
.netinheritance
user282807
user282807

Reputation: 925

Hide inherited member in client project

I have an interface with a method Validate() and an abstract class that implement this interface, and made a class called CustomerValidator that inherit the abstract class, also have entity Customer inherit CustomerValidator so i can call customer.Validate() in the library project.

my scenario is that i dont want the validate method to be available on the client code..if they new up a customer they should only see the entity properties..ex fistname ect. How do i hide the validate method? Thanks

Upvotes: 0

Views: 250

Answers (4)

bitxwise
bitxwise

Reputation: 3594

I must also ask why Customer inherits CustomerValidator, but also why is CustomerValidator abstract? I would suggest you change your interface and implementation as follows:

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

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

Then, if you insist on being able to do something like

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

I would suggest you use C# extension methods like this:

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);
    }
}

Note the internal scope so that clients cannot use this call.

As for using composition, I don't think Customer should know anything about CustomerValidator or ICustomerValidator. Those external responsibilities are outside the scope of a Customer class. If anything, CustomerValidator can have a Customer property if you insist on using composition, but I think the interface should take in a Customer parameter instead.

Upvotes: 0

user282807
user282807

Reputation: 925

I know Customer is not a CustomerValidator ..maybe the name makes a little confusion, but in my case i have the Customer implement the CustomerValidator where the validation rules gets added in the constructor and keep the Customer class clean. But I found the answer to my question, so what i did is Implement the Interface where the validate method is Explicitly. So on the client code validate is not visible in the Customer entity.

Upvotes: 0

Ray
Ray

Reputation: 396

I can think of a slightly different way how to organize your classes. The part you want the client to know about (the class "customer") contains all seeable properties. Internally in your lib you use wrapper classes that include the customer entity. So your librabry works with a full set of methods, using the wrapper classes that include the customer class but have more methods, and the client passes the costumer class to your lib which wraps it before continueing.

Upvotes: 0

Oded
Oded

Reputation: 499132

Instead of inheritance, use composition.

Why does your Customer class inherit from CustomerValidator? It is not a CustomerValidator, is it?

You can have a private CustomerValidator field in your Customer class - you can call Validate on it.

My example is in C#, though the principle applies to Java and other OOP lanaguages:

// 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);

Upvotes: 2

Related Questions