I'm fairly new to OOP (and programming in general), but what I find myself doing is that in the event that I don't need to pass a value from one method to another, I'll have my method calls centralized in some class within a Form.cs file.

For example:

public void CentralMethod()
{
MethodA();
MethodC();
MethodD();
}

MethodA() will then do some stuff and call MethodB() directly, to which it passes a value. However after MethodB() is done, control reverts back to CentralMethod() and then MethodC() is called, etc.

I can see how this is a nightmare on a large project, but is this at all a habit that one should get into on a relatively small project? I didn't necessarily do this by design, but I found myself doing it when it didn't make logical sense to include some method calls within other methods.

Only having MethodAMethodB, etc. it's impossible to say. It might be exactly the right way to solve the problem, and it may be a terrible way. Both are possible depending on what the methods are actually doing, and what their "relationship" to each other is.
–
ServyJan 10 '13 at 22:30

This looks like pretty standard fare for a procedural program. Doesn't really take advantage of OO. It's a valid way to write a program but as complexity increases (which it always does) you'll probably find it difficult to maintain.
–
Kenneth CochranJan 10 '13 at 23:00

Functional approach to writing code is always better; And implementing generalization and delegation surely helps (irrespective of the size of the app), but depends on the scenario. In your case, understanding the "Law of Demeter" is the key.
–
Tathagat VermaJan 11 '13 at 6:36

1 Answer
1

You mentioned that your rationale for calling methods this way is when the methods don't pass parameters from one to another. What exactly do you mean by that?

If you mean that the methods are not directly related to a single process (for instance, a PerformMaintenance() method that calls CleanCache() and then CheckForDeadOrders()), then this makes sense. This is a single main method that has several sections, performed independently, but that are a part of the same logical unit of work.

However, if by "don't pass parameters" you mean "use shared member variables", it might be a problem. If you have something like this:

where the methods share data, but each simply modifies the _orders variable, then yes, I'd say this is bad practice. It's bad practice because it saves persistent state for no reason, which makes your code less thread-safe and possibly prone to other bugs. It's bad practice because the flow of data between the methods isn't clear, since it's not implicit in their contract - a LoadOrders() that returned a list of orders that is then passed to SortOrders would be more explicit.