Learn some of the API design practices you should use when designing a Java API. These practices are generally useful and will allow your API to be properly used in modular environments such as OSGi and the Java Platform Module System (JPMS). Some practices are prescriptive, others proscribed, and of course other good API design practices apply too. Java Course in Pune
OSGi environments provide a modular runtime environment that enforces type visibility encapsulation using the concept of Java class loaders. Each module has its own class loader and can connect to the class loaders of other modules to share exported packages or use imported packages.
Introduced in Java 9, JPMS provides a modular platform that enforces type accessibility encapsulation using the access control concepts from the Java Language Specification. Each module defines which packages it exports and therefore can access from other modules. By default, all modules in a JMPS layer are in the same class loader.
Packages can contain APIs. These API packages have two client roles: API consumer and API provider. API consumer consumes the API implemented by API provider.
The following design practices describe the public parts of a package. Package members and types that are not public or protected (i.e. private or default accessible) are not accessible outside the package and therefore represent implementation details of the package.
Java packages should be coherent and stable units
Java packages should be designed to be coherent and stable units. In modular Java, a package is the common unit between modules. A module can export a package to make that package available to other modules. Because a package is the common unit between modules, the package must be consistent. h. All types in a package should be relevant to the specific purpose of the package. Grab-bag packages like java.util are discouraged because types in such packages are often unrelated to each other. Such inconsistent packages can cause a lot of dependencies because unrelated parts of a package point to other unrelated packages and a change to one aspect of a package affects all modules that depend on that package, even if only one module contains the changed part. package packages cannot be used at all. Because a package is a shared entity, its contents must be known, and the API it contains can only change in compatible ways as the package evolves in future releases. This means that a package cannot support an API superset or subset. For example, consider javax.transaction as a package whose contents are unstable. Users of a package must be able to know what types are available in the package. This also means that a package should be delivered from a single entity (such as a JAR file) and not split into multiple entities, because users of a package need to know that the entire package exists. Java Classes in Pune
Additionally, a package must evolve in a compatible way in future releases. Therefore, packages should be versioned and their version numbers should evolve according to semantic versioning rules. There is also an OSGi white paper on semantic versioning.
However, the semantic versioning recommendation for major package version changes is problematic: package development should be an enhancement of functionality. In semantic versioning, this is a minor version increment. If you want to remove a feature rather than bump the major version, i.e. make an incompatible change to your package, you should switch to a new package name while keeping the original package compatible. To understand why this is important and necessary, read this document on Semantic Import Versioning in Go and this excellent keynote presentation by Rich Hickey at Clojure/conj 2016. Both of them argue for moving to a new package name rather than changing the major version when you have an incompatible change. Packaged.
Minimize packet coupling
Types in one package can reference types in other packages, for example, parameter and return types of methods, field types, etc. This package coupling creates what is called a usage constraint for a package. This means that API consumers must use the same referenced packages as API providers so that they can both understand the referenced types.
In general, you want to minimize this packet coupling to minimize packet usage constraints. This simplifies wiring resolution in an OSGi environment, minimizes dependency dispersion, and simplifies deployment. Java Training in Pune
Prefer interfaces over classes
For APIs, prefer interfaces over classes. This is a fairly common API design technique and is also important for modular Java. Using interfaces not only allows freedom of implementation, but also allows for multiple implementations. Interfaces are important for decoupling API consumers from API providers, so that a package containing API interfaces can be used by both API providers who implement the interface and API consumers who invoke methods on the interface. This allows API consumers to have no direct dependency on API providers. Both depend only on the API package.
There are cases where abstract classes instead of interfaces are a valid design choice, but interfaces are generally the first choice, especially since standard methods can be added to the interface.
Finally, APIs often need lots of small concrete classes, such as event types and exception types. That’s fine, but the types should generally be immutable and not intended to be subclassed by API consumers.
