Java: The Factory Method Pattern

In this blog post, Justin Albano talks about the Factory Method Pattern and gives us an example.

The Textbook Definition

According to the Gang of Four book that defined the technique, the intent of the Factory Method pattern is as follows:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Using the Factory Method involves creating two sets of interfaces: “(1) the product interface that constitutes the object to be created and (2) the creator interface that constitutes the object that will instantiate the product.” The UML diagram for the Factory Methods is below:

The author explains the UML diagram as the following:

Using the general pattern, we build a Creator interface, which includes one or more Factory Methods, as well as any number of other methods. This interface may also be an abstract class with defined methods or even a default implementation of the Factory Method that returns a default instance of Product. From this interface, a set of ConcreteCreator classes are created that return desired ConcreteProduct instances that implement the Product interface.

An Example in Java

  • We create an encryption mechanism that allows the user to supply a string of text and a file name, which is then encrypted and written to disk. Using the Factory Method allows us to use multiple encryption algorithms.
  • We create implementations for two encryption algorithms: (1) SHA-256 and (2) SHA-512. “For both implementations, we will use the Apache Commons encryption implementations (org.apache.commons.codec.digest.DigestUtils).”
  • In the end you should be able to do something like this:

    PersistedFile file =
       new PersistedFile("/foo/bar/text.txt", "Hello, world!",
    new Sha256Encryptor());

    View complete example here

    Colloquial Definition

    A method whose sole responsibility is to abstract the creation process of an object and return that object.

    I chose this resource because I am interested to learn new implementations of popular design patterns such as the Factory Method. This resource gave a detailed explanation along with other patterns that can be good alternatives to the Factory Method pattern like the Template Method pattern and Strategy Pattern. I believe the content of the article is very detailed and informative. The example they used is very interesting and I’m going to implement the code myself to test it out. I plan to use this and many other design patterns in the future. I learned more about the Factory Pattern method and when it is appropriate to use it.

    Code Quality: Fighting Primitive Obsession Code Smells

    In this blog post, Anna Makowska talks about primitive obsessions code smells and what you can do to fix them. The author chose to focus on primitive bbession code smell because some smells are harder for developers to detect intuitively.

    “Primitive data types are basic built-in building blocks of a language. They’re usually typed as int, string, or constants. As creating such fields is much easier than making a whole new class, this leads to abuse. Therefore, this makes this smell one of the most common ones.”


    • Using primitive data types to represent domain ideas. For example, using an integer to represent an amount of money or a string for a phone number.
    • Using variables or constants for coding information. An often-encountered case is using constants for referring to users roles or credentials (like const USER_ADMIN = 1).
    • Using strings as field names in data arrays.


    • Code becomes less flexible because of use of primitives instead of objects.
    • Primitive data types are much harder to control. As a result, we may get variables that aren’t valid (supported by the type) or meaningful.
    • Primitives are often related to dedicated business logic. Therefore, leaving this logic unseparated may violate the Single Responsibility Principle and the Open/Closed Principle.
    • When data type logic is not separated in a dedicated class, adding a new type or behavior makes the basic class grow and get unwieldy.
    • By using primitives, the developer loses the benefits that come with object-oriented design, like data typing by class name or type hinting.

    Replace Data Value With Object

    • Instead of a set of primitive values, the programmer has full-fledged classes with all the benefits that object-oriented programming has to offer (typing data by class name, type hinting, etc.).
    • There is no need to worry about data validation, as only expected values can be set.
    • When relationship logic extends, it will be placed in one place dedicated to it.

    I chose this resource because it had plenty of good information on the primitive obsession code smell, when it’s going to lead to problems and how to fix that. I learned two more fixes, Replace Type Code With Subclasses, State, or Strategy (patterns) and Replace Array With Object for when “values of a coded type aim to control the behavior of the program.” I felt the content to be quality content from a author who has experience with spotting and fixing code smells. I will use this information in the future, by keeping an eye out for primitive obsession code smells.

    What Is Project Valhalla?

    In this blog post, Justin Albano explains what Project Valhalla is.

    “Project Valhalla is an OpenJDK project started in 2014 and headed by Brian Goetz with the purpose of introducing value-based optimizations to Java Development Kit (JDK) 10 or a future Java release. The project is primarily focused on allowing developers to create and utilize value types, or non-reference values that act as though they are primitives. In the words of Goetz: Codes like a class, works like an int.”

    “Project Valhalla has a very specific purpose: To cease the requirement that Java developers choose between performance and abstraction.”

    What Are Value Types?

    “Value types are groups of data whose immediate value is stored in memory, rather than a reference (or pointer) to the data.” Doing this means saving memory otherwise taken up by overhead data. “Taking data and directly placing its value into memory (rather than a reference) is called flattening and its benefits are more acutely demonstrated with arrays.” “In an array of value types, the values are directly placed into the array and are guaranteed to be in contiguous memory (which increases locality and, consequently, the chance of cache hits). This idea is illustrated in the figure below:

    The benefits to using Value Types are listed by the author:

    • Reduced memory usage: There is no need for additional memory used to store object metadata.
    • Reduced indirection: Because objects are stored as reference types in Java, each time you access it, it first must be dereferenced, causing additional instructions to be executed.
    • Increased locality Using flattened value objects removes indirection, increasing likelihood values are adjacently stored in memory.

    One of the major differences between reference types and value types:

    “The identity of a reference type is intrinsically bound to the object while the identity of a value type is bound to its current state”

    The reason I picked this resource is because I did not know about Project Valhalla and it seemed like an interesting article to learn about. It’s not quite ready to be released in JDK but it’s a useful addition to Java that increasing performance and saves memory. I feel the content of the post was interesting and informative. I learned the benefits of using Value Types versus using pointers and the improvements that have been made to Java. Value Types may soon be released in an upcoming JDK and I would like to know how to utilize them when saving memory is crucial.

    Additional resource: Minimal Value Types article

    Creating Your Code Review Checklist

    In this blog post, Erik Dietrich goes over creating a code review checklist. If you were to Google “Code review checklist”, the author lists results that may show up:

    • Does every method have an XML comment?
    • Do classes have a copyright header?
    • Do fields, methods, and types follow our standard naming convention?
    • Do methods have too many parameters?
    • Are you checking validity of method parameters?
    • Does the code have “magic” values instead of named constants?

    He then goes on to list two problems with going through a sometimes lengthy checklist:

    • You can’t keep 100+ items in your head as you look at every method or clause in a code base, so you’re going to have to read the code over and over, looking for different things.
    • None of the checks I listed above actually require human intervention. They can all be handled via static analysis.

    His suggestion for stream-lining the process of going through a big checklist is to automate the easy stuff. “Get static analysis tools that developers can install in their IDEs and run prior to delivering code, which will flag violations as errors or warnings. Get static analysis tools that run on the build machine and fail the build for violations.”

    Code Review for the Important Stuff

    The author lists an example checklist for a code author:

    • Does my code compile without errors and run without exceptions in happy path conditions?
    • Have I checked this code to see if it triggers compiler or static analysis warnings?
    • Have I covered this code with appropriate tests, and are those tests currently green?
    • Have I run our performance/load/smoke tests to make sure nothing I’ve introduced is a performance killer?
    • Have I run our suite of security tests/checks to make sure I’m not opening vulnerabilities?

    The author lists an example checklist for a code reviewer

    • Does this code read like prose?
    • Do the methods do what the name of the method claims that they’ll do? Same for classes?
    • Can I get an understanding of the desired behavior just by doing quick scans through unit and acceptance tests?
    • Does the understanding of the desired behavior match the requirements/stories for this work?
    • Is this code introducing any new dependencies between classes/components/modules and, if so, is it necessary to do that?
    • Is this code idiomatic, taking full advantage of the language, frameworks, and tools that we use?
    • Is anything here a re-implementation of existing functionality the developer may not be aware of?

    I chose this resource because it had very useful information on code review, which ties into QA. I feel the content of the article is very informational and useful to my future career. It is a good starting point for making sure you have thoroughly checked the quality of your code and automated tests are only going to increase in use, so it makes sense to automate what you can.

    API Design with Java 8

    In this blog post, Per-Åke Minborg talks about the fundamentals of good API design. His inspiration for writing this article is a blog post by Ference Mihaly which is essentially a check-list for good Java API design.

    “API combines the best of two worlds, a firm and precise commitment combined with a high degree of implementation flexibility, eventually benefiting both the API designers and the API users.”

    Do not Return Null to Indicate the Absence of a Value

    Using the Optional class that was introduced in Java 8 can alleviate Javas problem with handling nulls. An example below shows the implementation of the Optional class.

    Without Optional class

    public String getComment() {
        return comment; // comment is nullable

    With Optional class

    public Optional getComment() {
        return Optional.ofNullable(comment);

    Do not Use Arrays to Pass Values to and From the API

    “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 List which has a set() method).”

    Not exposing a Stream

    public String[] comments() {
        return comments; // Exposes the backing array!

    Exposing a Stream

    public Optional getComment() {
        return Optional.ofNullable(comment);

    Consider Adding Static Interface Methods to Provide a Single Entry Point for Object Creation

    Adding static interface methods allows the client code to create onjects 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.”

    Not using static interface methods

    Point point = new PointImpl(1,2);

    Using static interface methods

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

    I selected this resource because it relates to design principles, and it’s something that I do not know well. I would like to learn more about APIs and good practices for designing them using Java. The article had useful information and topics that I didn’t know well. A few more pointers from the article I learned:

    • Favor Composition With Functional Interfaces and Lambdas Over Inheritence – Avoid API inheritance, instead use static interface methods that take “one or several lambda parameters and apply those given lambdas to a default internal API implementation class.”
    • Ensure That You Add the @FunctionalInterface Annotation to Functional Interfaces – signals that API users may use lambdas to implement the interface
    • Avoid Overloading Methods With Functional Interfaces as Parameters – Can cause lambda ambiguity on the client side.

    I would like to learn more about using AWS Lambdas, and learning more about APIs in general. I plan to use this information if I am ever to work on Java APIs which is possible. I want to make sure I have the best practices and the check list mentioned in the start of the article seems like a good starting point.