注:本文转载于http://www.cnblogs.com/xing901022/p/5854506.html,感谢xingoo!html
经过函数做为策略有两个要注意的地方:java
下面举个简单的例子,针对Engineer类提供不一样的策略作排序,好比按照年龄或者按照员工级别:ide
class Engineer{ private String name; private int age; private int level; public Engineer(String name,int age,int level) { this.name = name; this.age = age; this.level = level; } public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } public int getLevel() { return level; } public void setLevel(int level) { this.level = level; } } public class Strategy { public static final Comparator<Engineer> AGE_ORDER = new AgeComparator(); public static final Comparator<Engineer> LEVEL_ORDER = new LevelComparator(); private static class AgeComparator implements Comparator<Engineer>{ @Override public int compare(Engineer e1, Engineer e2) { return e1.getAge()-e2.getAge(); } } private static class LevelComparator implements Comparator<Engineer>{ @Override public int compare(Engineer e1, Engineer e2) { return e1.getLevel()-e2.getLevel(); } } public static void main(String[] args) { List<Engineer> el = new ArrayList<>(); el.add(new Engineer("zhangsan", 26, 3)); el.add(new Engineer("lisi", 30, 2)); el.add(new Engineer("wangwu", 28, 1)); Collections.sort(el,AGE_ORDER); System.out.println(JSON.toJSON(el)); Collections.sort(el,LEVEL_ORDER); System.out.println(JSON.toJSON(el)); } }
在上面的例子中,采用静态成员变量声明,能够在屡次使用的时候节省建立对象的成本。并且静态成员在堆内存的分配上也更简单,不会每次都建立新的对象。函数
在真实的场景中,是在某个请求方法里面,返回一个List对象,须要对它按照日期排序。若是是普通的Collections.sort(list,new Comparator<xx>{})
这种方式,会在每次返回结果的时候,都建立一个匿名类,很显然会浪费很多内存空间,增长垃圾回收的压力。使用静态成员变量的方式,能够减小这种没必要要的浪费。this
因为在1.5以前的版本,java是没有泛型概念的。所以在引入泛型后,须要考虑到之前代码的移植。spa
没有泛型的时候,若是使用List,能够往里面插入任意类型的值。可是在取得时候,若是类型不对就有问题了:设计
List list = new ArrayList(); list.add(1); String list0 = list.get(0);//出错
为了不这种问题,1.5引入泛型,这样一套代码能够适用于多种类型;还能在编译器就检查类型是否一致。rest
List<E> xxx
标准的泛型,java还提供了无限制性的泛型:<?>意思是未知类型,就是不设上下限 <? extend Object>意思是继承于Object的未知类型 <? super Object>意思是Object的祖先类型 |
因此,尽可能使用标准的格式,在某些状况下已知的一些通配限制,还可使用<?>号加以限制。code
记得最开始本身写代码的时候,满满的都是黄色标记,师兄就纠正个人作法,让我把这些警告全都去掉。其实随时保证没有警告的代码,才是最负责的作法。不论是本身屏蔽掉,仍是作相应的解决,都好过编译的时候爆出一大堆警告好。htm
Java是一门编译型的语言,须要通过编译,变成class字节码才能执行。可是在编写泛型相关的代码时,老是会遇到一些警告。好比参数仅仅声明为Map,没有声明具体内部的内容等等。
在Eclipse中能够经过加入@SuppressWarning
注解来忽略警告,可是不推荐这种作法。除非你对本身的代码很是自信,保证不会出现其余的类型,而致使ClassCastException。因此尽可能在写代码的时候不要产生警告,若是想要忽略,尽可能考虑清楚入口出口是否不会出现意外。
经常使用的就是unckecked和rawtypes,一个是不检查内部变量,一个是不检查参数类型。
all to suppress all warnings boxing to suppress warnings relative to boxing/unboxing operations cast to suppress warnings relative to cast operations dep-ann to suppress warnings relative to deprecated annotation deprecation to suppress warnings relative to deprecation fallthrough to suppress warnings relative to missing breaks in switch statements finally to suppress warnings relative to finally block that don’t return hiding to suppress warnings relative to locals that hide variable incomplete-switch to suppress warnings relative to missing entries in a switch statement (enum case) nls to suppress warnings relative to non-nls string literals null to suppress warnings relative to null analysis rawtypes to suppress warnings relative to un-specific types when using generics on class params restriction to suppress warnings relative to usage of discouraged or forbidden references serial to suppress warnings relative to missing serialVersionUID field for a serializable class static-access to suppress warnings relative to incorrect static access synthetic-access to suppress warnings relative to unoptimized access from inner classes unchecked to suppress warnings relative to unchecked operations unqualified-field-access to suppress warnings relative to field access unqualified unused to suppress warnings relative to unused code |
作业务需求,仍是须要了解些业务知识才行。不管是电商环境,仍是传统企业,环比和同比是最多见的数据分析手段,能够经过对比明显的看到当前业务的变化趋势,有利于管理层即便作出调整,那么什么是环比,什么是同比呢?
举个例子:
太业务化的东西,就不说了,省得设计到什么尴尬的信息。
睡觉时间到,养好精神,才能专一...