Applying correctly interface segregation principle in my UML diagram

Question

Context: Object oriented programing student, learning SOLID principles and trying to apply them in my school project. Making a Indeed-like website to apply for jobs using Windows form and a web application. Have to use a design patter that consists in presentation layer, logic layer and data access layer. Trying to apply interface segregation in the part where users on the webapp can send application(job solicitation) and the admin can react to those applications in windows form.

This was my initial UML diagram:

I have one class in my data access layer to do CRUD in Sql. The interfaces are in the logic layer and the controllers will be used in the presentation layer, one for the winsform and the other one for web application.

And this was my teacher's feedback:

1. AppController should implement the seggregated interfaces.
2. Front-end selects the correct interface based on its requirements (User or Vacancy requirements).
3. See the AppController as such.
4. Now there is an ellaborate construction with two dedicated controllers that negate the benefit of interface seggregation.

So I changed it like this:

And I feel like this is correct cause

1. I have two segregated interfaces
2. I use controllers that I need depending if it's for winsform or the web app.

Additionally, In the front end, I'll be using the controllers so:

• for the webapp ApControllerForU controller = new ApControllerForU(new SendingApplicationDal());

• for the winsform ApControllerForV controller = new ApControllerForV(new ReactingToApplicationDal());

So I think my reasoning is justified.. but not very sure. Can you tell me if this is correct?

Answer 1

The main purpose of the Interface Segregation Principle is not to multiply interfaces by unnecessarily segregating them; it's about avoiding to merge in an interface operations that are not always relevant and required. In other words, it's about separation of concerns.

Your two segregated interfaces ISendingApplication and IReactingToApplication both inherit interface IApplication. This implies that SendingApplicationDal and ReactingToApplicationDal both need to implement all the IApplication methods. The question is: are GetApplication() and UpdateApplication() relevant in both cases, and moreover, are all the arguments of these methods relevant in both cases (unfortunately we cannot see)? If the answer is "no" to either part of the question, you're not ISP compliant.

By the way: It seems that your business logic interface uses the active record pattern which is is implemented in the DAL. This architectural pattern is only suitable for simpler domains. Unfortunately, while you added differentiation between interfaces, you don't show in the business logic the very different nature between updating an application as applicant and reacting to application. An admin should react and should not be allowed to modify/falsify other elements of the application. So it's not only about providing a method, but also to define the contract that users of the interface can rely on. Hence, in your design, at the same time you complexify the matter with duplication, but at the same time for a core operation, you oversimplify, by reducing them simple UpdateApplication(), i.e. a technical update of some db record.