Return to Answer

Because the purpose of the method is defined on the level of the object (student), not the fields therein (name and age).

While your code might currently display students using their name and age, showStudentInfo(Student s) and showNameAndAge(string name, int age) are different methods with different purposes.

The purpose of the showStudentInfo is to, well, show the student's info. If tomorrow you decided that this also includes their student ID, then the method hasn't really changed its purpose, it has only changed its implementation of that purpose.

At its very core, a method signature (i.e. name and parameters) focuses on the purpose of the method (i.e. what does this method do?), whereas the method body focuses on the implementation of that purpose (i.e. how can we achieve what we want this method to do?)

If you were to using name/age parameters, what you'd be doing is saying that the purpose of the method is to display a name and an age.

Taking this to an extreme, what if names are printed in a very unique reusable way (e.g. UPPERCASE), and ages too (in their own unique way, e.g. as a binary number)? Well, you'd end up with something like:

public void ShowStudentInfo(Student s) { ShowName(s.Name); ShowAge(s.Age); } 

Three methods, all with very different purposes and implementations.

• ShowStudentInfo's purpose is to display a student's info. Its implementation consists of choosing which student fields to use. This method does not care how the fields get rendered, it only picks the fields that should be rendered (and passes them to the appropriate rendering method).
• ShowName's purpose is to display a name in the unique way that names should be shown, its implementation being one that uppercases the string. This method does not care whether the name came from a student or not.
• ShowAge's purpose is to display an age in the unique way that ages should be shown, its implementation being one that converts an integer into a stringified binary digit sequence. This method does not care whether the age came from a student or not.

which looks as if one of the disadvantage of "global state" that has "hidden dependency"

Global state is really wide. It can be pretty much everything under the sun.

By comparison, having a method take in a Student parameter still restricts that method to only being able to access Student properties. That's still decidedly more narrow than giving access to a global scope.

Furthermore, the implication here is that no one is hydrating the Student object based on their knowledge of what showStudentInfo is going to rely on. You're going to find that generally speaking a Student is going to be treated as an atomic data object that is fully hydrated, regardless of which methods rely on which Student properties.

You're not wrong that in a sense, an input parameter and a dependency are the same thing on a technical level as far as the compiler cares; on a semantical level they represent very different roles and developers innately have different expectations on how to treat them and rely on them.

Because the purpose of the method is defined on the level of the object (student), not the fields therein (name and age).

While your code might currently display students using their name and age, showStudentInfo(Student s) and showNameAndAge(string name, int age) are different methods with different purposes.

The purpose of the showStudentInfo is to, well, show the student's info. If tomorrow you decided that this also includes their student ID, then the method hasn't really changed its purpose, it has only changed its implementation of that purpose.

At its very core, a method signature (i.e. name and parameters) focuses on the purpose of the method (i.e. what does this method do?), whereas the method body focuses on the implementation of that purpose (i.e. how can we achieve what we want this method to do?)

If you were to using name/age parameters, what you'd be doing is saying that the purpose of the method is to display a name and an age.

Taking this to an extreme, what if names are printed in a very unique reusable way (e.g. UPPERCASE), and ages too (in their own unique way, e.g. as a binary number)? Well, you'd end up with something like:

public void ShowStudentInfo(Student s) { ShowName(s.Name); ShowAge(s.Age); } 

Three methods, all with very different purposes and implementations.

• ShowStudentInfo's purpose is to display a student's info. Its implementation consists of choosing which student fields to use. This method does not care how the fields get rendered, it only picks the fields that should be rendered (and passes them to the appropriate rendering method).
• ShowName's purpose is to display a name in the unique way that names should be shown, its implementation being one that uppercases the string. This method does not care whether the name came from a student or not.
• ShowAge's purpose is to display an age in the unique way that ages should be shown, its implementation being one that converts an integer into a stringified binary digit sequence. This method does not care whether the age came from a student or not.

which looks as if one of the disadvantage of "global state" that has "hidden dependency"

Global state is really wide. It can be pretty much everything under the sun.

By comparison, having a method take in a Student parameter still restricts that method to only being able to access Student properties. That's still decidedly more narrow than giving access to a global scope.

Furthermore, the implication here is that no one is selectively and partially hydrating the Student object based on their knowledge of what showStudentInfo is going to rely on. You're going to find that generally speaking a Student is going to be treated as an atomic data object that is fully hydrated, regardless of which methods rely on which Student properties.

You're not wrong that, in a sense, an input parameter and a dependency are the same thing on a technical level as far as the compiler cares. However, on a semantical level they represent very different roles and developers innately have different expectations on how to treat them and rely on them.

Because the purpose of the method is defined on the level of the object (student), not the fields therein (name and age).

While your code might currently display students using their name and age, showStudentInfo(Student s) and showNameAndAge(string name, int age) are different methods with different purposes.

The purpose of the showStudentInfo is to, well, show the student's info. If tomorrow you decided that this also includes their student ID, then the method hasn't really changed its purpose, it has only changed its implementation of that purpose.

At its very core, a method signature (i.e. name and parameters) focuses on the purpose of the method (i.e. what does this method do?), whereas the method body focuses on the implementation of that purpose (i.e. how can we achieve what we want this method to do?)

If you were to using name/age parameters, what you'd be doing is saying that the purpose of the method is to display a name and an age.

Taking this to an extreme, what if names are printed in a very unique reusable way (e.g. UPPERCASE), and ages too (in their own unique way, e.g. as a binary number)? Well, you'd end up with something like:

public void ShowStudentInfo(Student s) { ShowName(s.Name); ShowAge(s.Age); } 

Three methods, all with very different purposes and implementations.

• ShowStudentInfo's purpose is to display a student's info. Its implementation consists of choosing which student fields to use.
• ShowName's purpose is to display a name in the unique way that names should be shown, its implementation being one that uppercases the string.
• ShowAge's purpose is to display an age in the unique way that ages should be shown, its implementation being one that converts an integer into a stringified binary digit sequence.

which looks as if one of the disadvantage of "global state" that has "hidden dependency"

Global state is really wide. It can be pretty much everything under the sun.

By comparison, having a method take in a Student parameter still restricts that method to only being able to access Student properties. That's still decidedly more narrow than giving access to a global scope.

Furthermore, the implication here is that no one is hydrating the Student object based on their knowledge of what showStudentInfo is going to rely on. You're going to find that generally speaking a Student is going to be treated as an atomic data object that is fully hydrated, regardless of which methods rely on which Student properties.

You're not wrong that in a sense, an input parameter and a dependency are the same thing on a technical level as far as the compiler cares; on a semantical level they represent very different roles and developers innately have different expectations on how to treat them and rely on them.

Because the purpose of the method is defined on the level of the object (student), not the fields therein (name and age).

While your code might currently display students using their name and age, showStudentInfo(Student s) and showNameAndAge(string name, int age) are different methods with different purposes.

The purpose of the showStudentInfo is to, well, show the student's info. If tomorrow you decided that this also includes their student ID, then the method hasn't really changed its purpose, it has only changed its implementation of that purpose.

At its very core, a method signature (i.e. name and parameters) focuses on the purpose of the method (i.e. what does this method do?), whereas the method body focuses on the implementation of that purpose (i.e. how can we achieve what we want this method to do?)

If you were to using name/age parameters, what you'd be doing is saying that the purpose of the method is to display a name and an age.

Taking this to an extreme, what if names are printed in a very unique reusable way (e.g. UPPERCASE), and ages too (in their own unique way, e.g. as a binary number)? Well, you'd end up with something like:

public void ShowStudentInfo(Student s) { ShowName(s.Name); ShowAge(s.Age); } 

Three methods, all with very different purposes and implementations.

• ShowStudentInfo's purpose is to display a student's info. Its implementation consists of choosing which student fields to use. This method does not care how the fields get rendered, it only picks the fields that should be rendered (and passes them to the appropriate rendering method).
• ShowName's purpose is to display a name in the unique way that names should be shown, its implementation being one that uppercases the string. This method does not care whether the name came from a student or not.
• ShowAge's purpose is to display an age in the unique way that ages should be shown, its implementation being one that converts an integer into a stringified binary digit sequence. This method does not care whether the age came from a student or not.

which looks as if one of the disadvantage of "global state" that has "hidden dependency"

Global state is really wide. It can be pretty much everything under the sun.

By comparison, having a method take in a Student parameter still restricts that method to only being able to access Student properties. That's still decidedly more narrow than giving access to a global scope.

Furthermore, the implication here is that no one is hydrating the Student object based on their knowledge of what showStudentInfo is going to rely on. You're going to find that generally speaking a Student is going to be treated as an atomic data object that is fully hydrated, regardless of which methods rely on which Student properties.

You're not wrong that in a sense, an input parameter and a dependency are the same thing on a technical level as far as the compiler cares; on a semantical level they represent very different roles and developers innately have different expectations on how to treat them and rely on them.

Because the purpose of the method is defined on the level of the object (student), not the fields therein (name and age).

While your code might currently display students using their name and age, showStudentInfo(Student s) and showNameAndAge(string name, int age) are different methods with different purposes.

The purpose of the showStudentInfo is to, well, show the student's info. If tomorrow you decided that this also includes their student ID, then the method hasn't really changed its purpose, it has only changed its implementation of that purpose.

At its very core, a method signature (i.e. name and parameters) focuses on the purpose of the method (i.e. what does this method do?), whereas the method body focuses on the implementation of that purpose (i.e. how can we achieve what we want this method to do?)

If you were to using name/age parameters, what you'd be doing is saying that the purpose of the method is to display a name and an age.

Taking this to an extreme, what if names are printed in a very unique reusable way (e.g. UPPERCASE), and ages too (in their own unique way, e.g. as a binary number)? Well, you'd end up with something like:

public void ShowStudentInfo(Student s) { ShowName(s.Name); ShowAge(s.Age); } 

Three methods, all with very different purposes and implementations.

• ShowStudentInfo's purpose is to display a student's info. Its implementation consists of choosing which student fields to use.
• ShowName's purpose is to display a name in the unique way that names should be shown, its implementation being one that uppercases the string.
• ShowAge's purpose is to display an age in the unique way that ages should be shown, its implementation being one that converts an integer into a stringified binary digit sequence.

Because the purpose of the method is defined on the level of the object (student), not the fields therein (name and age).

While your code might currently display students using their name and age, showStudentInfo(Student s) and showNameAndAge(string name, int age) are different methods with different purposes.

The purpose of the showStudentInfo is to, well, show the student's info. If tomorrow you decided that this also includes their student ID, then the method hasn't really changed its purpose, it has only changed its implementation of that purpose.

At its very core, a method signature (i.e. name and parameters) focuses on the purpose of the method (i.e. what does this method do?), whereas the method body focuses on the implementation of that purpose (i.e. how can we achieve what we want this method to do?)

If you were to using name/age parameters, what you'd be doing is saying that the purpose of the method is to display a name and an age.

Taking this to an extreme, what if names are printed in a very unique reusable way (e.g. UPPERCASE), and ages too (in their own unique way, e.g. as a binary number)? Well, you'd end up with something like:

public void ShowStudentInfo(Student s) { ShowName(s.Name); ShowAge(s.Age); } 

Three methods, all with very different purposes and implementations.

• ShowStudentInfo's purpose is to display a student's info. Its implementation consists of choosing which student fields to use.
• ShowName's purpose is to display a name in the unique way that names should be shown, its implementation being one that uppercases the string.
• ShowAge's purpose is to display an age in the unique way that ages should be shown, its implementation being one that converts an integer into a stringified binary digit sequence.

which looks as if one of the disadvantage of "global state" that has "hidden dependency"

Global state is really wide. It can be pretty much everything under the sun.

By comparison, having a method take in a Student parameter still restricts that method to only being able to access Student properties. That's still decidedly more narrow than giving access to a global scope.

Furthermore, the implication here is that no one is hydrating the Student object based on their knowledge of what showStudentInfo is going to rely on. You're going to find that generally speaking a Student is going to be treated as an atomic data object that is fully hydrated, regardless of which methods rely on which Student properties.

You're not wrong that in a sense, an input parameter and a dependency are the same thing on a technical level as far as the compiler cares; on a semantical level they represent very different roles and developers innately have different expectations on how to treat them and rely on them.