3

Probably best explained with an example:

In a .NET C# project, we have a library class for which several function accept an HttpContext as one of the arguments.

The thing is, that none of the functions actually need the full HttpContext, they just need one item from one of the collection properties on the HttpContext.

I need to convey the idea that having a method parameter that is more than what the function actually needs to run is sub optimal because it:

a) Requires the caller to have more than what they might in order to call the function.

b) Makes testing harder.

c) Is potentially less performant.

But my googling has not helped me find canonical terminology for this.

Does it exist?

gbro3n
  • 481
  • 2
  • 8
  • That was quick. Go on then, why the -1? Pretty sure you didn't even have time to read it. – gbro3n Oct 03 '19 at 11:06
  • Request to close is marked as 'Primarily opinion based'. The question is ultimately "Does it exist?". Existence is not something that's opinion based. – gbro3n Oct 03 '19 at 11:14
  • This is not opinion based, it's a well known principle. It's the I in SOLID. candied_orange has the right answer. – Blake Oct 03 '19 at 11:33

3 Answers3

7

The Interface Segregation Principle states that:

No client should be forced to depend on methods it does not use

Wikipedia - Interface Segregation Principle

So shoving bloated objects into clients without a narrowing interface that shows the clients actual needs violates the principle.

A method parameter that only contains what is needed would satisfy the principle, so would a narrow interface between HttpContext and the client. Either way will show what the clients actual needs are. No more. No less.

Community
  • 1
candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • That sounds like the correct principle. I find the language around that principle quite hard to interpret. Is the client being forced to "depend" on a "method" here? Rather it is forced "provide" or "implement" functionality that is not required by the dependency maybe. Maybe it's just the the language needs to be broad / slightly vague to capture everything it intends. – gbro3n Oct 03 '19 at 11:44
  • @bg2d the "depend" word is a little hard to grasp. It has to do with fancy math concepts that explain why arrows point in the directions they do in UML diagrams. Here depend basically means to build this as designed you need that. Put simply the principle is saying that designing clients to need things they don't use is just silly. – candied_orange Oct 03 '19 at 12:05
  • 1
    @gb2d: This principle is expressed in terms of OOP, but the principle itself is more general. In terms of OOP, the client is an object that uses another object, and the functions in question are the interfaces (public methods) of those other objects. In case of function parameters of an isolated function, the client code is the function itself, and the dependencies are whatever parameters you pass into it - may be data structures, may be proper OOP objects with their own behavior, or other functions. The principle in this case is about how you design the function signature. – Filip Milovanović Oct 03 '19 at 18:58
  • 1
    It's a bit subtle, though. To paraphrase Robert C. Martin (Wikipedia ref 5), ISP acknowledges that you may need to have object that provide "fat" (unsegregated) interfaces, but suggests that you don't have to design clients to expect "fat" interfaces in a dependency/parameter. I.e., a function could accept that one object, but it's more flexible to segregate parameters by responsibility, because then you can (a) use the same object for each parameter, or (b) replace any of those with a different object that implements the same interface. – Filip Milovanović Oct 03 '19 at 18:59
  • 1
    Additionally, in strongly typed languages, if you have several different clients that use different parts of the interface, and you have to change some part of the interface, it affects all of them, even though some of the clients don't use that part at all. – Filip Milovanović Oct 03 '19 at 19:00
  • This is good, +1. I never thought about applying the ISP to method signatures. Often it feels ‘wrong’ to pass some dto with 6 properties to a method that only uses 2, but I never had a good argument why it felt ‘wrong’. – Rik D Oct 03 '19 at 19:45
  • @RikD: Be careful, though - as this introduces complexity, you don't want to indiscriminately apply it everywhere (whether we are talking about object dependencies or function signatures); you can go overboard. It's a balancing act between complexity and convenience, and you want to apply it in those places where it reduces (maintenance) complexity elsewhere (or provides some other benefit that's worth to you). You also may want to wait before you apply it to a part of the codebase that's still early in development, until you see certain patterns stabilize, so that you know how to segregate. – Filip Milovanović Oct 03 '19 at 22:09
  • @FilipMilovanović this is true. Usually this is carefully applied at boundaries where code is likely to change. It tends to be followed much more loosely within boundaries. – candied_orange Oct 03 '19 at 22:39
1

This is known as the Principle of Least Knowledge or The Law of Demeter.

RubberDuck
  • 8,911
  • 5
  • 35
  • 44
  • I think this is the most concise term for the principle I described. Thanks – gbro3n Oct 05 '19 at 18:38
  • Not the issue that comes to mind when the complaint is that the parameter "is more than what the function actually needs to run". [Demeter](https://softwareengineering.stackexchange.com/a/284146/131624) tells you not to ask your friends to introduce you to their friends. You end up having to know how to find them and it leaves you talking to strangers rather than friendly abstractions. Doesn't really talk about anything being to much. But apparently it's what the OP wanted. Wish I understood why. – candied_orange Oct 06 '19 at 02:56
  • @candied_orange OP mentioned that the function didn’t require the whole object, but just one if its properties. This is the context I was taught about the Law of Demeter in. If you pass the whole object into the function, it “has to introduce you to its friend”. The function doesn’t need to know about the whole `HttpContext`, thus the Principle of Least Knowledge. – RubberDuck Oct 06 '19 at 09:06
  • I see, you're focused on the line about needing "one item from one of the collection properties". Might be worth explaining that in your answer. – candied_orange Oct 06 '19 at 12:40
0

I would not label this ISP. ISP is not about limiting client access, it is about isolating behavioral aspects. What you are referring to is maintaining tight scope. You do not want (the method's) code to see more than what is relevant to its purpose, thus eliminating noise for the reader and inhibiting the code to do things it is not supposed to do.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57