Are there adverse effects of passing around objects rather than assigning them as members of a class

I have a habit of creating classes that tend to pass objects around to perform operations on them rather than assigning them to a member variable and having operations refer to the member variable. It feels much more procedural to me than OO.

Is this a terrible practice? If so, what are the adverse effects (performance, memory consumption, more error-prone)? Is it simply easier and more closely aligned to OO principles like encapsulation to favour member variables?

A contrived example of what I mean is below. I tend to do the following;

public class MyObj()
{

  public MyObj() {}

  public void DoVariousThings(OtherObj oo)
  {
    if (Validate(oo))
    {
       Save(oo);
    }
  }

  private bool Validate(OtherObj oo)
  {
    // Do stuff related to validation
  }

  private bool Save(OtherObj oo)
  {
     // Do stuff related to saving
  }

}

whereas I suspect I should be doing the following;

public class MyObj()
{

  private OtherObj _oo;

  public MyObj(OtherObj oo) 
  {
    _oo = oo;
  }

  public void DoVariousThings()
  {
    if (Validate())
    {
       Save();
    }
  }

  private bool Validate()
  {
    // Do stuff related to validation with _oo
  }

  private bool Save()
  {
     // Do stuff related to saving with 开发者_开发知识库_oo
  }
}

---

If you write your programs in an object oriented language, people will expect object oriented code. As such, in your first example, they would probably expect that the reason for making oo a parameter is that you will use different objects for it all the time. In your second example, they would know that you always use the same instance (as initialized in the constructor).

Now, if you use the same object all the time, but still write your code like in your first example, you will have them thoroughly confused. When an interface is well designed, it should be obvious how to use it. This is not the case in your first example.

---

I think you already answered your question yourself, you seem to be aware of the fact that the 2nd approach is more favorable in general and should be used (unless there are serious reasons for the first approach).

Advantages that come to my mind immediately:

• Simplified readability and maintainability, both for you and for others
• Only one entry point, therefore only needing to checking for != null etc.

• In case you want to put that class under test, it's way easier, i.e., getting something like this (extracting interface IOtherObj from OtherObj and working with that):

  public MyObj (IOtherObj oo)  
  {
      if (oo == null) throw...
      _oo = oo;
  }
  

---

Talking of the adverse effects of your way, there are none, but only if you are keeping the programs and the code to yourself,, what are you doing is NOT a standard thing, say, if after some time, you start to work making libraries and code that may be used by others also, then it is a big problem. The may pass any foo object and hope that it would work.

you have to validate the object before passing it and if the validation fails do things accordingly, but if u use the standard OOP way, there is no need for validation or taking up the cases where an inappropriate type object is pass,

In a nutshell, your way is bad for : 1. code re-usability. 2. you have to handle more exceptions. 3. okay, if u r keeping things to urself, otherwise, not a good practice.

hope, it cleared some doubt.