Dzone指南：现代Java开发深度解析

需积分: 6 25 浏览量更新于2024-07-18 收藏 4.51MB PDF 举报

"Dzone Modern Java 是一份针对现代Java开发者的指南，由Dzone发布，包含多个专题，深入探讨了Java的最新发展、设计原则、项目管理以及生产力提升等关键领域。" 本文集涵盖了广泛的现代Java开发主题，旨在帮助Java开发者跟上技术的步伐，提升效率并优化代码风格。以下是对各个部分的详细解读： 1. **Executive Summary**（执行摘要）：这部分可能概述了Java持续流行的原因，包括其跨平台的特性、易读性以及内存管理的不断改进。 2. **Key Research Findings**（关键研究发现）：可能提供了关于Java开发者面临的挑战、行业趋势以及成功实践的调查结果。 3. **The Java 8 API Design Principles**（Java 8 API设计原则）：作者Per Minborg讨论了Java 8引入的新特性，如lambda表达式和流API，以及如何遵循良好的设计原则来利用这些新功能。 4. **Project Jigsaw is Coming**（项目Jigsaw即将到来）：Nicolaiparlog介绍了Java模块化系统Project Jigsaw，解释了它如何影响项目的结构和依赖管理，以及对开发者的影响。 5. **Reactive Microservices: Driving Application Modernization Efforts**（反应式微服务：推动应用程序现代化的努力）：Mark Usele探讨了反应式编程如何通过微服务架构提高应用程序的性能和可扩展性。 6. **Checklist: 7 Habits of Super Productive Java Developers**（清单：超级生产力Java开发者的7个习惯）：提供了一套实践建议，帮助开发者提高开发效率和代码质量。 7. **The Elements of Modern Java Style**（现代Java风格的元素）：Michael Tofinetti分析了编写清晰、简洁且易于维护的Java代码的最佳实践。 8. **12 Factors and Beyond in Java**（Java中的12要素及其超越）：Pieter Humphrey和Mark Heckler阐述了如何在Java应用中实现12要素原则，以构建云原生的应用程序。 9. **Diving Deeper into Java Development**（深入Java开发）：这部分可能深入讲解了高级Java开发概念和技术，如并发、垃圾回收或高级数据结构。 10. **Infographic: Java's Impact on the Modern World**（信息图：Java对现代世界的影响）：用可视化的方式展示了Java在各种领域，如互联网、移动应用和大数据等中的广泛应用。 11. **A Java Developer’s Guide to Migration**（Java开发者迁移指南）：Ben Wilson提供了关于如何平滑地将旧项目迁移到最新Java版本的策略和步骤。 12. **HashTables, Mutability, and Identity: How to Implement a Bidirectional HashTable in Java**（哈希表、可变性和身份：如何在Java中实现双向哈希表）：Wayne Citrin讨论了数据结构的设计和实现，特别是关于Java中的不可变性和双向关联的数据结构。 13. **Executive Insights into Java Development**（对Java开发的高层见解）：Tom Smith可能分享了他对Java开发行业的见解，包括最佳实践、挑战和未来预测。 14. **Java Solutions Directory**（Java解决方案目录）：这部分可能列出了适用于不同场景的Java库、框架和工具，为开发者提供了一个参考资源。 15. **Glossary**（词汇表）：提供了与Java开发相关的术语和概念的定义，有助于理解和学习。这份指南对于任何想要深入了解现代Java开发实践的开发者来说都是宝贵的资源，涵盖了从基础到高级的各种主题，可以帮助他们提升技能，适应不断变化的技术环境。

DZONE’S GUIDE TO MODERN JAVA

DZONE.COM/GUIDES DZONE’S 2016 GUIDE TO MODERN JAVA

Anyone that writes Java code is an API

designer! It does not matter if the coders

share their code with others or not, the code

is still used; either by others, by themselves or

both. Thus, it becomes important for all Java

developer to know the fundamentals of good

API design.

A good API design requires careful thinking and a lot

of experience. Luckily, we can learn from other clever

people like Ference Mihaly, whose blog post inspired me

to write this Java 8 API addendum. We relied heavily on

his checklist when we designed the Speedment API. (I

encourage you all to read his guide.)

Getting it right from the start is important because once

an API is published, a rm commitment is made to the

people who are supposed to use it. As Joshua Block once

said: “Public APIs, like diamonds, are forever. You have

one chance to get it right, so give it your best.” A well

designed API combines the best of two worlds, a rm

and precise commitment combined with a high degree of

implementation exibility, eventually beneting both the

API designers and the API users.

Why use a checklist? Getting the API right (i.e. dening

the visible parts of a collection of Java classes) can be

much harder than writing the implementation classes that

makes up the actual work behind the API. It is really an art

that few people master. Using a checklist allows the reader

to avoid the most obvious mistakes, become a better

programmer and save a lot of time.

API designers are strongly encouraged to put themselves

in the client code perspective and to optimize that view

in terms of simplicity, ease-of-use, and consistency—

rather than thinking about the actual API implementation.

At the same time, they should try to hide as many

implementation details as possible.

DO NOT RETURN n ull TO INDICATE THE ABSENCE

OF A VALUE

Arguably, inconsistent null handling (resulting in the

ubiquitous NullPointerException) is the single largest

source of Java applications’ errors historically. Some

developers regard the introduction of the null concept

as one of the worst mistakes ever made in the computer

science domain. Luckily, the rst step of alleviating Java’s

null handling problem was introduced in Java 8 with the

advent of the Optional class. Make sure a method that

can return a no-value returns an Optional instead of n ull.

This clearly signals to the API users that the method may

or may not return a value. Do not fall for the temptation to

use null over Optional for performance reasons. Java 8’s

escape analysis will optimize away most Optional objects

anyway. Avoid using Optionals in parameters and elds.

DO THIS:

public Optional<String> getComment() {

return Optional.ofNullable(comment);

}

DON’T DO THIS:

public String getComment() {

return comment; // comment is nullable

}

Learn to be a better Java

programmer by mastering Java 8

API design and:

• Expose a well designed API

and hide the implementation

details

• Make sure that client code can

use lamdas

• Ensure that the API can evolve

in a controlled way

• Get rid of all those nasty

NullPointerExceptions

QUICK VIEW

The Java 8

API Design

Principles

BY PER MINBORG

CTO AT SPEEDMENT, INC.

DZONE’S GUIDE TO MODERN JAVA DZONE’S GUIDE TO MODERN JAVA

DZONE.COM/GUIDES DZONE’S 2016 GUIDE TO MODERN JAVA

DO NOT USE ARRAYS TO PASS VALUES TO AND

FROM THE API

A signicant API mistake was made when the Enum concept

was introduced in Java 5. We all know that an Enum class

has a method called values() that returns an array of

all the Enum’s distinct values. Now, because the Java

framework must ensure that the client code cannot change

the Enum’s values (for example, by directly writing to

the array), a copy of the internal array must be produced

for each call to the value() method. This results in poor

performance and also poor client code usability. If the Enum

would have returned an unmodiable Lis t, that List could

be reused for each call and the client code would have had

access to a better and more useful model of the Enum’s

values. In the general case, consider exposing a Stream, if

the API is to return a collection of elements. This clearly

states that the result is read-only (as opposed to a Lis t

which has a set() method). It also allows the client code to

easily collect the elements in another data structure or act

on them on-the-y. Furthermore, the API can lazily produce

the elements as they become available (e.g. are pulled in

from a le, a socket, or from a database). Again, Java 8’s

improved escape analysis will make sure that a minimum

of objects are actually created on the Java heap. Do not

use arrays as input parameters for methods either, since

this—unless a defensive copy of the array is made—makes

it possible for another thread to modify the content of the

array during method execution.

DO THIS:

public Stream<String> comments() {

return Stream.of(comments);

}

DON’T DO THIS:

public String[] comments() {

return comments; // Exposes the backing array!

}

CONSIDER ADDING STATIC INTERFACE METHODS

TO PROVIDE A SINGLE ENTRY POINT FOR OBJECT

CREATION

Avoid allowing the client code to directly select an

implementation class of an interface. Allowing client code to

create implementation classes directly creates a much more

direct coupling of the API and the client code. It also makes

the API commitment much larger, since now we have to

maintain all the implementation classes exactly as they can

be observed from outside instead of just committing to the

interface as such. Consider adding static interface methods,

to allow the client code to create (potentially specialized)

objects that implement the interface. For example, if we

have an interface Point with two methods int x() and

int y(), then we can expose a static method Point.of(int

x, int y) that produces a (hidden) implementation of the

interface. So, if x and y are both zero, we can return a special

implementation class PointOrigoImpl (with no x or y

elds), or else we return another class PointImpl that holds

the given x and y values. Ensure that the implementation

classes are in another package that are clearly not a part

of the API (e.g. put the Point interface in com.company.

product.shape and the implementations in com.company.

product.internal.shape).

DO THIS:

Point point = Point.of(1,2);

DON’T DO THIS:

Point point = new PointImpl(1,2);

FAVOR COMPOSITION WITH FUNCTIONAL

INTERFACES AND LAMBDAS OVER INHERITANCE

For good reasons, there can only be one super class for

any given Java class. Furthermore, exposing abstract

or base classes in your API that are supposed to be

inherited by client code is a very big and problematic

API commitment. Avoid API inheritance altogether, and

instead consider providing static interface methods that

take one or several lambda parameters and apply those

given lambdas to a default internal API implementation

class. This also creates a much clearer separation of

concerns. For example, instead of inheriting from a public

API class AbstractReader and overriding abstract void

handleError(IOException ioe), it is better to expose

a static method or a builder in the Reader interface that

takes a Consumer<IOException> and applies it to an

internal generic Rea derImpl.

DO THIS:

Reader reader = Reader.builder()

.withErrorHandler(IOException::printStackTrace)

.build();

DON’T DO THIS:

Reader reader = new AbstractReader() {

@Override

public void handleError(IOException ioe) {

ioe. printStackTrace();

}

};

ENSURE THAT YOU ADD THE FunctionalInterface

ANNOTATION TO FUNCTIONAL INTERFACES

Tagging an interface with the @FunctionalInterface

annotation signals that API users may use lambdas to

implement the interface, and it also makes sure the

interface remains usable for lambdas over time by

preventing abstract methods from accidently being added

to the API later on.

DO THIS:

@FunctionalInterface

public interface CircleSegmentConstructor {

CircleSegment apply(Point cntr, Point p, double ang);

// abstract methods cannot be added

}

CONTINUED

剩余53页未读，继续阅读

ysihaoy

粉丝: 1
资源: 16

Dzone指南：现代Java开发深度解析

DZone：2018年大数据技术指南

java8看不到源码-IntroduceToEclicpseVert.x:该存储库包含我在kodcu.com、medium、dzone等平台上

C4DZone Grass Painter v2.0

dzone社区年度报告-apachekafka.pdf

DZone_REST_Refcard_2011 E文

dzone-unique-url:适配 dropzone amd 模块

dzonefeed:dzone.com链接和文章rss feed聚合器

C4D距离测量工具 C4DZone MeasureIt v1.0 R12-_R16

独立5G网络中MEC部署的UE应用启动和卸载 - DZone IoT1

商业微服务：具有Spring Boot 2.0，Eureka和Spring Cloud的微服务-Dzone教程

最新资源