当我们开始学习编程时,是在面向过程中起步的,hello world!是我们的第一条可见运行结果,main是约定俗成的入口。
在业务逻辑不断变得复杂时,可共用的执行片段慢慢抽象出方法,方法实现了接收参数并稳定输出结果的任务,相同的入参获取到相对稳定的出参。为什么叫相对稳定,因为计算机是有精度限制的,它无法准确表述是有数值,转而使用了相对准确的计数方法。
当有了方法后,入参与与出参形成了基本的变量体系。让计算机根据接收的输出相对稳定的结果。面向过程中的业务基本在这就结束了。
main入口--->执行方法---->方法嵌套。
随着业务应用的推进与代码规模的变化。对于管理类性能要求相对较低的系统构建,引入了模块化/组件化方案,并在进入main之后在面向过程的底层基础服务之上构建了面向对象设计模式,方面被封装成了类的成员,但还是接收输入参数计算后输出相对稳定的结果。只是调用层级上加入了对象的概念。
变量有很多,全局变量/局部变量/系统变量/上下文变量等。
他们在控制着执行逻辑的改变。
变量是代码的一个延伸,在产品发布后能不调整代码的情况下修改运行逻辑,这是在代码编写前预留的调整空间,如jvm开放了大量的参数,在不同的场景下进行相应的修改,最终实现相对有化的运行性能。
变量怎么注入呢?代码固化的有全局变量/局部变量/线程上下文变量等。
局部变量影响范围较小,只影响片段。
线程上下文变量,将影响一个线程执行的生命周期内的方法。也就是可以在不同的方法直接,使用上下文变量传入参数,达到隐式传参的目的。但有问题是怎么解决线程池共用线程后参数初始化问题。
全局变量是系统级的,将影响到整个运行进程的所有执行点。
在系统级设计中,不仅仅要设计出特定的业务实现,还需要从整体出发,构建出多层次数体系,为后续参数调优提供可能。
在微服务/微应用架构体系下,配置中心取代了配置文件。但原理还是需要在各个进程应用中开放出参数变量体系。