I have some general questions about encapsulation as it relates to maintainability. Here is an example class that I used to assist in the construction of a parse tree. (I have avoided STL for education's sake.)

The `Node` class describes a node in a tree. The managing class `ParseTree` (not shown) is responsible for building and maintaining the collection of `Node` objects in a meaningful, tree-like way.

```
// contents of node.h, not including header guard or namespace
class Token;
class Node {
public:
  static const Node* FindParent(const Node* p_root, const Node* p_node);
  static int Height(const Node* p_root);
  static void Print(const Node* p_root);
  Node(const Token * p_tok=0) : p_left_(0), p_right_(0), p_tok_(p_tok) {}
  ~Node() { delete p_left_; delete p_right_; }
  const Node* p_left(void) const { return p_left_; }
  const Node* p_right(void) const { return p_right_; }
  const Token* p_tok(void) const { return p_tok_; }
private:
  friend class ParseTree;
  Node* p_left_;
  Node* p_right_;
  Token* p_tok_;
};

```

The following four topics relate to encapsulation.

1. The static methods in the `Node` class are declared static because they can be phrased without using any private members. I'm wondering if they should live outside `Node` in a common namespace, or maybe as static members within `ParseTree`. Should my decision be dominated by the fact that `ParseTree` is responsible for trees, and by that logic the functions should live in `ParseTree`?
2. On a related note, the reason the static methods are in `Node` instead of `ParseTree` was because `ParseTree` was filling up with lots of members. I've read that keeping class small and agile is better for maintainability. Should I be going out of my way to find methods that don't rely on private member access and pull them out of my class definition and put them into functions grouped within the same namespace as the class?
3. I had also read some advice about avoiding mutators on private members since it tends to break encapsulation, so I ended up only having accessors, and let `ParseTree` handle any modifications using its friendship with `Node`. Is this really better than having mutators and just ending the friendship with `ParseTree`? If I add mutators, then `Node` can be reused in other contexts without adding another friendship.
4. If I add mutators and remove the static functions from `Node`, I feel like I could just make the data members public and remove all the accessors/mutators/friend declarations. I have the impression that such an approach would be bad form. Should I be skeptical of my design if I have accessor/mutator pairs for each private member?
5. If there's anything else obvious and wrong about my approach that I didn't think to ask, I'd appreciate hearing about it.