لطفا منتظر باشید ...
Methods
Methods are the workhorses of your classes. When you call a method, it executes some code. It may, but doesn''t have to, return some value directly. It may also take some parameters, but again, it doesn''t have to.
In Visual Basic .NET, methods appear in the syntax with the name Function or Sub, as in "subroutine." This is largely a throwback to the old Basic days where the same piece of code was used several places throughout the program. "Subroutine" really isn''t a good name for a method because it implies that it lives all by itself and is not critical to the design of the class. For example, if you call the Unlock() method of the MyCar object with MyCar.Unlock(), you aren''t calling a subroutine at allyou''re calling code to manipulate that instance of the object. It''s not generally used by the application at-large.
You''ve already seen a number of different methods as they appear in your class code, as well as how to call them from an instantiated object. They may be declared not to return any kind of value, like the method in Listing 2.9.
Listing 2.9. Basic method with no return value
C#
public void MyMethod()
{
// some code
}
VB.NET
Public Sub MyMethod()
'' some code
End Sub
If you''d like the method to return some kind of value, you''ll need to declare its type in the method declaration, and then at some point (or points) in the method, you''ll need to return the value with the return keyword, as shown in Listing 2.10.
Listing 2.10. A method that returns a string
C#
public string MyMethod()
{
return "some string";
}
VB.NET
Public Function MyMethod() As String
Return "some string"
End Function
Notice the difference in syntax compared to Listing 2.8, where the method does not return a value, especially if you''re using VB.NET. When you need to return a value, you use the Function syntax instead of the Sub syntax. In C#, when you don''t intend to return any value, you use the pseudo-type void.
You probably have used methods that return a value, even if you haven''t used that value. For example, if you''ve called the ExecuteNonQuery() method of a SqlCommand object, that method returns an integer indicating the number of rows in the database that were affected by your command (i.e., myInteger = SomeSqlCommand.ExecuteNonQuery()). If you don''t capture that value, it''s simply not used.
Methods can give you something back, but you also can put something into a method as well by feeding it parameters. A method can have any number of parameters of any types. Listing 2.11 shows a method that takes a string and an int.
Listing 2.11. Method with parameters
C#
public void MyMethod(string myName, int myAge)
{
Trace.Warn(myName);
Trace.Warn(myAge.ToString());
}
VB.NET
Public Sub MyMethod(myName As String, myAge As Integer)
Trace.Warn(myName)
Trace.Warn(myAge.ToString())
End Sub
You can now see that there are really two primary ways to get data in and out of your instantiated objects. You can use parameters and return values in your methods, or you can assign and read values from properties.
Alternatively, you can do both. We''ll look closer at both approaches in Chapter 3, "Class Design."
Public methods can be called from any instance of the class. So what good are private methods? Suppose you have some common piece of code that other methods in the class need to call, but you don''t want that common code to be called directly from an instance of the class. Marking the method private accomplishes this, and it''s a handy way to avoid code duplication in your class.
