0

I've a service called Claims-Service which has following signature:

IClaimsService { EnsureClaim(claimType, userId) }

It queries database to see if the claim is present in any of my roles or not.

Based on my current requirements, I don't have a scenario which requires a user to have more than one claim to do something, but I think I'm going to need it in near future. (I'm in the very beginning of the project)

Is it ok to add following method to my service or not?

EnsureClaims( claimTypes, userId )

So I can pass array of claim types to it.

What pros and cons do you see if I develop the second method in my service?

Note that EnsureClaim and EnsureClaims need their own queries and there won't be any type of code re use. So I'm talking about developing new codes, automated tests & code review. And I'm not talking about huge amount of new codes.

Yaser Moradi
  • 109

2 Answers2

1

There is much to consider when making a decision like this. Some of the questions you need to get answers for include:

  • Can you afford to take the time to develop and test the currently unused code?
  • Will it add additional requirements (like additional memory)?
  • How likely is it that you'll actually need this feature in the near future?
  • Will this additional code need to be rewritten for whatever version it is used in because something else changed?
  • Will the tests need to be updated as the product evolves between when you add the feature and when it is actually needed?
  • Will the new code introduce any additional points that can be exploited (security vulnerabilities)?
  • Are there be development assets available now that can be used to add the feature that will not be available in the future?

If you do eventually add the feature, you'll still need to go thru the testing phase.

This usually resolves itself to "No, don't add the second service now."

1201ProgramAlarm
  • 1,559
1

This seems like something you can add fairly easily at any point (especially if this service if new, in terms of its life-cycle as a product, since in that case the cost of rewriting whole chunks of code is probably low).

While it is OK to add support for anticipated features, especially where they can be expected with a degree of certainty and are well understood (assuming you otherwise exercise YAGNI-like restraint where appropriate), since you say there's no code reuse, I would leave this for later. Even though it's not a huge amount of new code, you may end up needlessly complicating things, or you may make some wrong assumptions which could get in your way later.

A better thing to focus on instead is to make sure that the code that uses the claims service (and other things related to claims) doesn't depend on the fact that the code behind it checks for a single claim (i.e, is not written in a way that relies on that), so that you can introduce the change later easily with minimal consequences. So, check for that, and refactor if necessary.

Filip Milovanović
  • 9,480