189 8069 5689
要是类名直接调用的方法，那这个方法就是静态的(static)方法，是不用new出新对象实例就可以直接调用的方法。例子如下：
为临西等地区用户提供了全套网页设计制作服务，及临西网站建设行业解决方案。主营业务为成都做网站、成都网站制作、成都外贸网站建设、临西网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
class A{
public static void Method1(int a, int b){
//方法体
}
类名的命名是有讲究的，类名、属性名、变量名一般是名词，或者是形容词+名词。
方法一般是动词，或者是动词+名词，以AnnotationTest作为类名和以TestAnnotation作为类名是有区别的，前者是注解的测试，符合名词的特征，后者是测试注解，听起来就是一个动作名称，是方法的命名特征。
扩展资料
关键词主要有static和abstract两个关键词。有static修饰的方法叫做静态方法。没有的则叫非静态方法。其中我们最熟悉的main方法就有static 修饰。这个方法也是我最不熟悉搞不懂的方法。
static方法一般称作静态方法，由于静态方法不依赖于任何对象就可以进行访问，因此对于静态方法来说，是没有this的。因为它不依附于任何对象，既然都没有对象，就谈不上this了。
用static修饰的方法。由于类方法是属于整个类的，所以类方法的方法体中不能有与类的对象有关的内容。即类方法体有如下限制：
1、类方法中不能引用对象变量；
2、类方法中不能调用类的对象方法；
3、在类方法中不能调使用super，this关键字；
4、类方法不能被覆盖。
说到代码优化，每个人或多或少都掌握一到两种方法，但是这样的方法对提升代码运行效率效果不大，最重要是对代码的重视和了解，这样才能提升代码的运行效率。在进行代码优化的过程中，方法是非常重要的，多掌握几种方法，根据代码的不同情况选择适合的方法进行优化。下面电脑培训为大家介绍Java代码优化的几种方法。
1、使用指定类、方法的final修饰符
具有final修饰符的类不可派生。在Java核心API中，有许多最终应用程序的例子，例如java.lang.String，整个类都是final。为类指定final修饰符允许继承类，并且为方法指定final修饰符允许覆盖该方法。如果将类指定为final，IT培训认为该类的所有方法都是final。Java编译器将寻找内联所有最终方法的机会。内联对于提高Java操作的效率非常重要。这可以将性能平均提高50％。
2、重用对象
String对象的使用是非常重要的，StringBuilder/StringBuffer并不是字符串连接。由于Java虚拟机需要时间来生成对象，所以将来垃圾收集和处理这些对象可能需要一些时间。因此，生成太多对象将对程序的性能产生很大影响。
3、使用局部变量
调用方法时传递的参数以及在调用中创建的临时变量都保存在堆栈中，速度更快。其他变量（如静态变量和实例变量）在堆中创建并且速度较慢。此外，回龙观北大青鸟发现在堆栈中创建的变量，当方法完成运行时，内容消失，不需要进行额外的垃圾收集。
4、及时关闭流
在Java编程过程中，在执行数据库连接和I/O流操作时要小心。使用后，北大青鸟回龙观校区官网建议应及时关闭以释放资源。因为这些大型物体的操作会导致系统的大量开销，稍微粗心会导致严重的后果。
public class Message {
public static void main(String[] args){
String name;
int age;
System.out.println("请输入姓名，回车结束："); //提示输入
Scanner sc = new Scanner(System.in);
name = sc.nextLine(); //为变量赋值
System.out.println("请输入年龄，回车结束：");
age = sc.nextInt();
System.out.println("姓名："+name+"\n年龄："+age); //打印姓名及年龄
}
}
//不知道这样行么？
一、不要使用魔法数字，尽量定义枚举、常量、宏：
我常常见到表示各种状态的数字，0，1，2....，我真的不知道这表示什么含义，如果
你在不在文档中说明的话，这个东东过几天连你自己都不知道个一二三了。
二、命名要具有描述力，尽量使用全名而不是自创的缩写，除非地球人都这么用这个缩写：
我常常看到一些自创的缩写，这个缩写或许只有你自己知道，类名，方法名，参数名
尤其要有好的描述里，局部变量尚可容忍。我宁可容忍超过40个字符的命令，也不愿意
看到只有一两个字母的命名，当然迭代用的i,j除外。当然命名不要太长，太长说明你的类和
方法要做的事情太多，请你拆分出更多细粒度功能单一的类和方法。
三、同一类东东命名方式尽可能统一，比如类名使用大写字母开头的单词，变量使用
下划线分割开来的小写字母单词，常量使用下滑线分割的开来的大写字母单词。不要
交替使用。
四、函数、类功能尽可能单一，不要试图写一个万能/超级函数或者类。
一个类和方法要有单一的职责，这样的类和方法只做一件事，并且容易把他做好。
1、不要试图写一个强大无比的方法。
我常常看到一些试图写的多么“精妙”无比多么“强大”的函数，事实上不是什么精妙，而是
代码的臭味道。精妙强大无比万能的方法往往你耗费大量精力去设计算法，试图覆盖现在的各
种可能，而无法面对将来新的需求，随着新的需求，你的这个精妙的方法需要的修改并且改起来
极其痛苦。在一次次的痛苦与精妙的演化中，你的方法越来越复杂，并且每一次修改你都会面
临影响以前功能的风险。这个方法使用者需要小心的处理你的精妙之处，如果没有精妙传递好参
数，那么这个方法再也不精妙了，而是直接废掉了。
KISS（keep it simple and stupid）原理就是这个道理，你要使你的代码尽可能简单，让人
看到有一目了然的清爽，而不是因为设计了一个精妙无比的万能方法而沾沾自喜。这里的简单不是
简洁的代名字。有时候简洁是那种传说的“精妙”的代码。
2、不要写做多件事情的方法和类，你做一件事情，你就写一个对应的方法，不要试图通过参数来判定各种情况，然后做事情，并且做的事情和你方法描述的不一致。当你发现你的方法名字想不出来好的名字了，或者要加or和and了，那么请你拆分出更多单一的方法。
不要举一些linux完成多种功能系统调用，这是被迫的，因为系统调用的数量是有限制的，它只有有限的空间来描述系统调用号和系统调用的映射表，不要在应用程序开发中效仿而误以为优雅强大。我最恶心根据参数，然后一大堆的if..else 和switch..case判断。
五、不要修改已有的类和方法而是扩展它。
这是程序设计的一个重要原则，开闭原则，在面向对象的语言中尤为重要。在面向过程中主要表现在，不要在一个函数要应对和这个函数相似的一个需求了，就在这个加个if，来修改这个方法，试图重用和避免重复。而是要把公用的部分抽出来成一个小的功能函数，然后增加一个应对新的类似这个需求的处理方法。在面向对象中，例如使用策略模式、访问者模式、Extend Object模式。
六、不要重复你自己（DRY）：
程序最怕的是copy,paste，到处是重复的代码。copy，paste经常被误以为快速完成需要用的功能的高效方式而被到处使用。你每重复一次，你就得负责保持他们的一致性，你就得在一处增加新的功能时，你就的把这个的功能加到其他地方。还在我刚会写代码的时候去了一个小公司，他们的代码到处是copy，paste的痕迹，当要在现有的功能增加审计功能是，他们开始下命令了，每个人加几行代码来做审计，真不知道那么多人写的审计版本，分散到那么多处，这个审计功能是否可信有用。
避免DRY的方法就是抽象，分离变化。不管是面向对象还是面向过程，分离变化并抽象之是最主要的设计原则。设计模式中的模板方法，我们常用的回调都是我们常用的方法。
我发现越是提供更多回调处理的语言和框架，就越具有灵活性和易用性。ruby语言之所以有如此的威力，主要是因为它提供了更多的回调处理。它可以在动态的给一个类增加方法，这样可以在超类中定义增加方法的方法，然后再子类调用，子类就具有无比的能力。它的block提供了强大的回调机制，我只要不知道如何处理了我就yield出来，method missing机制更是神秘无比，你可以写出像find_by_name_and_age,2.days.ago这样像自然语言一样易读的代码。
七、不要跨越边界，在适合的地方写代码。
在分层的架构中，不要跨越层的边界。例如web开发的三层架构:
数据访问层（DAO)、业务层(Service)、表现层。
不要在业务层裸写SQL来做事情，不要在业务层掺和进来表现层的东东，不要在表现层/控制器中写业务的东东。既然已经分层了，那么就要好好的遵守它，如果到处跨越边界的话，那么和不分层没有什么区别，使得每一层都不伦不类。例如你应该在业务层进行事务管理，而你的控制器到处是业务代码，那将无法控制。如果你的业务层到处是SQL，我不知道你的DAO存在的意义了。
八、分层的web架构：
DAO层最好按照模型来划分dao类，如果业务很简单，也可以将相关的模型合并为一个DAO。
Service层，不要按照DAO和Service一一对应的方式划分，而是要按照业务的类别和实际情况来划分。事实上Service层通常是用来处理涉及到多个模型的业务，而涉及到一个模型的业务，常常被放在模型中，这是一种自然而更面向对象的设计方法。只有数据的模型被称为贫血型模型，这种模型被认为是对面向对象的一种背离，而在模型中放置专有的业务方法，不仅有利于公用，而且模型更具有描述力。
九、关于MVC:
MVC是一种松耦合的设计方案，最容易误用的就是控制器（c）。控制器只负责调用业务方法，准备好数据供View去展现。而不要把业务和如何展示的东东放在里面。我常常看到有人在控制器中拼html片段和写一些业务相关的代码。
十、顺便说一下异常的使用。
如果你是使用语言支持异常机制，那么尽可能的使用异常机制和定义好与自己业务相关的异常，而不是通过返回值表示正确和错误。如果你使用的语言支持异常机制，请不要写类linux下c似的代码形式，每写一个函数，我就写一个判断返回值调用是否成功，严重分离了我对核心业务的关注。异常提供了优雅的处理错误的方法。