对于 ts 来说写 utils 模块的话是像强类型语言一样 public static 写法好还是直接 export 好

[hikarugo]

export class Utils {
  public static f(){}
}

export function f(){}

[crysislinux]

看这些方法是不是有同一个归宿吧。我倾向于把 utils 分类，一个类别一个文件，然后导出方法

[optional]

直接导出，tree shacking

[ChefIsAwesome]

当然直接 export 。简单就是美，搞什么花里胡哨的 class 。

[hsfzxjy]

你 public static 还不如 namespace

[rabbbit]

function foo() {}
export {foo}

import {foo} from 'util'
// or
import * as Util from 'util'

[codehz]

直接 export 的话方便优化（
最后打包的时候可能就只会留下用到的（
弄成 class 的话，那整个 class 都要留下了

[flyqie]

怎么感觉你以前像是写 java 的。。

万物都要来个 class ，真没必要这么干的。

[ochatokori]

类是工具，不是形式

[35aZ4P8mT576683q]

如果 Utils 里面有 private static 方法 /属性我觉得没什么问题，因为这样以来 class 下的方法可以归到一起，而且 private 关键字比用不加 export 的函数更能清晰的表达出 do NOT use me outside 的含义

[IvanLi127]

简单的 utils 一般是一个个函数吧，直接 export 就好了。不是纯面向对象的语言，没必要被迫抽象。

[rb6221]

强类型感觉好一点吧 这些工具类一般都是写了就几乎不会改的，而且用到的地方很关键，所以需要比较严格的安全和可靠性保证

[Vegetable]

为什么是 class...

[Trim21]

@liberty1900 这么一通操作没有意义....

class 的 private 方法在忽略类型错误的情况下还是可以调用的，但是你用 es module 的话私有函数是直接 undefined 的

[35aZ4P8mT576683q]

@Trim21 private 关键字确实只是类型上的约束。不过我感觉通过 class 把相关方法归类到一起还是有好处的，如果函数比较多，直接向外面暴露容易造成混乱，特别是函数名比较长的时候。

比如要 export 一堆和 time 相关的函数，其中两个是和 month 有关的:

```javascript
export function getNumberOfDaysInMonth(year: number, monthIndex: number)

export function getNameOfMonth(monthIndex: number)
```

直接向调用者暴露这些长函数名不那么友好，通过 class with static methods 就可以通过下面的方式调用:

```javascript
TimeUtils.Month.GetName
TimeUtils.Month.GetNumberOfDays
```

个人感觉这样更加优雅，只暴露一个 TimeUtils 给外面就够了，层级关系分明

当然 class with static methods 和直接创建一个 object 没什么区别就是了

[hsfzxjy]

@liberty1900 可以用 namespace

[YuTengjing]

java 是因为没法直接导出函数，啥都得用 class 封装，是没得选。

[justsosososo]

相信 LZ 是个喜欢搞前戏的人。。。。。

[churchill]

> Don't name code "Utils"

&t=19s&ab_channel=CodeAesthetic

[codehz]

@hsfzxjy ts 早就不推荐 namespace 了，之前 typescript compiler 内部改造，把 namespace 迁移到 esm （就直接导出的那种），性能快了好几个百分点