类的哪些行为应当定义在类内部、哪些应当定义在类外部？

方法放在类内部会不会导致每个实例内存上涨？ #

绝大多数主流面向对象编程语言（C++、Java、Python、C#等）的类成员方法，都是存储在类所属的公共方法区，不会给每个实例单独复制一份方法代码。每个实例只会存储自身独有的实例属性数据，所以就算你往Graph类里加几十上百个普通成员方法，单个Graph实例占用的内存也不会有任何变化，完全不需要有这方面的顾虑。

复杂行为放类内还是类外的通用设计准则 #

没有绝对的标准答案，通常可以参考以下几个设计原则判断：

• 按照单一职责原则划分：如果行为属于Graph的核心基础能力，比如增删节点/边、查询邻接节点、通用序列化等直接依赖内部结构的通用功能，优先放在类内部。如果是特定场景的扩展功能，比如针对某业务定制的图转换规则、导出为某领域专属格式这类非通用能力，放在类外部的工具函数/工具类更合适，避免核心类过度膨胀，后期维护混乱。
• 按照开闭原则判断：如果你的Graph类是需要对外提供的基础公共组件，后续会频繁新增扩展功能，优先把扩展功能放到类外部，不需要修改核心Graph的代码就能新增能力，降低对核心稳定逻辑的侵入风险。
• 按照访问成本判断：如果某功能需要大量访问Graph的私有内部结构才能实现，放在类内部可以避免暴露私有成员，也能减少冗余的属性访问代码，这种情况优先放类内部；如果功能完全可以通过Graph的公有接口实现，放在外部更灵活，也不会和核心类耦合。

举个实际的例子：通用的JSON序列化导出是所有Graph实例都可能用到的通用能力，放到类里做to_json()成员方法非常合理；但如果是导出符合某公司内部业务规范的JSON格式，需要额外拼接大量业务字段和特殊转换逻辑，就适合做成外部的export_to_biz_json(Graph g)独立函数。

规则是否和使用的编程语言有关？ #

是的，不同语言的特性会直接影响选型：

• 支持扩展方法的语言（C#、Kotlin、Rust、Python也可通过第三方库实现类似能力）：你可以把扩展功能做成扩展方法，既可以像调用类成员一样用g.convert_to_special_graph()的写法，又不用把代码塞到核心Graph类里，兼顾了易用性和单一职责。
• 不支持独立函数的纯面向对象语言（比如早期版本的Java）：如果不想膨胀核心类，只能把扩展功能放到单独的工具类中，比如GraphUtils.exportToBizJson(Graph g)。
• 支持多分派/泛型特化的语言：可以把不同的转换逻辑做成特化函数，针对不同的Graph子类走不同实现，也不需要把所有逻辑堆到核心类里。

补充提醒：很多人觉得类里方法多了不好，本质是职责划分不合理的问题，不是方法数量的问题。只要所有方法都属于Graph的核心职责，就算有几十个方法也没问题；如果是和核心能力无关的业务逻辑，哪怕只加一个也不该放到核心类中。

内容的提问来源于stack exchange，提问作者Alexis Pister