search

alejandrobabio / music-api

0 stars 1 forks source link

why passing in Musician Class instead of musician instance? #6

Open alex-nexus opened 6 years ago

alex-nexus commented 6 years ago 
UseCases::DeleteMusician.new(Musician).call(params[:id])

Can you please elaborate your design behind this line?

alex-nexus commented 6 years ago

also, the call function is quite short, do you still it is worth it to have a dedicated class for just 1 line?

def call(id)
  model_class.destroy(id)
  ''
end
alejandrobabio commented 6 years ago

Well, in #2 I commented the whys and hows of the standard that I defined, and I should stick to it if I don't want to make a mess. But the main reason to do this is to keep the responsibilities isolated and design the application in a way that each class has only one reason to change (again Uncle Bob), and the reason to change for the use case "delete musician" in a change in the policy of deleting musicians. On the other hand, the reason to change of the API MusicAPI::Musicians::Delete is a change in the endpoints definition.

alejandrobabio commented 6 years ago

About why pass the Class instead of the instance. It's about doing the things in the same way in all endpoints and knowing less about the AR DSL, leaving the job to the UseCase instance. In some cases could be complex to find the instance, and I want to keep the API clean. Perhaps we can dispose of passing the Class at all, and let the use case to use the AR DSL with the parameters already validated by the API.