What is the Correct Way to Call a Method That Has Been Overridden as Protected in Another Class from Another Class?

Question

Hello

I have Repository and service classes in my c# wpf project. For example, BookService, AuthorService, which inherit from BaseService. When adding DI, I add them via the interface and when using them, I inject and use them via the interface. BaseService includes basic CRUID and basic validation operations. As the project progressed, a need arose. For example, when saving a book, I added special validations by overriding the validate method in BaseService with BookService and finally I ensure that basic validations are applied by calling base.Validate(). This does not cause a problem for the Book object when the BookService works directly. However, when I try to call the Validate method, which is overridden in AuthorService while recording via BookService, I cannot access the AuthorService.Validate method via BookService because it is overridden in a protected manner. In order to prevent this and preserve the current structure, I defined an auxiliary public method and added it to the IAuthorService interface and developed a method to call validation for that service from another class.

Will such a usage cause me problems as the project grows? Can you suggest a different approach to achieve my goal?

The question is a bit long. Sorry,

Thank you.

Answer 1

In general - I would prefer composition over inheritance and use inheritance only in rare cases because it creates tight coupling, making changes harder to manage and reducing flexibility.

While your approach works, it introduces tight coupling since validation is bound to the service hierarchy, violating Separation of Concerns. I recommend moving validation to separate validator classes, making the system more modular, reusable, and testable

Answer 2

@fatih uyanık, Welcome to Microsoft Q&A, based on your description, your current approach works in the short term but may cause maintenance issues as the project grows.

Here are the main concerns:

1. Tight Coupling – BookService depends on IAuthorService validation, creating unnecessary dependencies.
2. Unclear Responsibilities – BookService handles both business logic and validation, which breaks the Single Responsibility Principle.
3. Poor Scalability – If more services require cross-validation, adding more public validation methods will make the code harder to manage.

I recommend that you create Separate Validator Classes to deal with Validate.

Here is a code example you could refer to.

public interface IBookValidator { void Validate(Book book); }
public class BookValidator : IBookValidator
{
    private readonly IAuthorValidator _authorValidator;
    
    public BookValidator(IAuthorValidator authorValidator)
    {
        _authorValidator = authorValidator;
    }
    public void Validate(Book book)
    {
        if (string.IsNullOrEmpty(book.Title))
            throw new ValidationException("Title is required.");
        
        _authorValidator.Validate(book.Author);
    }
}
public class BookService : IBookService
{
    private readonly IBookValidator _bookValidator;
    
    public BookService(IBookValidator bookValidator)
    {
        _bookValidator = bookValidator;
    }
    public void Save(Book book)
    {
        _bookValidator.Validate(book);
        // Proceed with saving
    }
}

By using the above method, you can know the following advantages:

1. Services stay focused on business logic.
2. Validators can be reused in multiple places.
3. Easier testing and maintenance.

Hope it could help you.

Best Regards,

Jack

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.