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?

  • That was quick. Go on then, why the -1? Pretty sure you didn't even have time to read it.
    – gb2d
    Oct 3, 2019 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.
    – gb2d
    Oct 3, 2019 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 3, 2019 at 11:33

3 Answers 3


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

  • I think this is the most concise term for the principle I described. Thanks
    – gb2d
    Oct 5, 2019 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 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. Oct 6, 2019 at 2: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 6, 2019 at 9: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. Oct 6, 2019 at 12:40

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.

  • 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.
    – gb2d
    Oct 3, 2019 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. Oct 3, 2019 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. Oct 3, 2019 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. Oct 3, 2019 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. Oct 3, 2019 at 19:00

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.