Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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() 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.

share|improve this question
Only having MethodA MethodB, 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. – Servy Jan 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 Cochran Jan 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 Verma Jan 11 '13 at 6:36

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:

private List<Order> _orders;
public Order FindMatchingOrder()
    return _orders.First();

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.

share|improve this answer
It can also make testing needlessly difficult. You might want to mock LoadOrders() in various ways and feel compelled to throw sensible visibility out the window. – Tim Post Jan 10 '13 at 23:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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