• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Image from Amazon
Title: Practical Design Patterns for Java Developers: Hone your software design skills by implementing popular design patterns in Java
Author(s): Miroslav Wengner
Publisher: Packt
Category: OO

Amazon wrote:Design patterns are proven solutions to standard problems in software design and development, allowing you to create reusable, flexible, and maintainable code. This book enables you to upskill by understanding popular patterns to evolve into a proficient software developer.

You'll start by exploring the Java platform to understand and implement design patterns. Then, using various examples, you'll create different types of vehicles or their parts to enable clarity in design pattern thinking, along with developing new vehicle instances using dedicated design patterns to make the process consistent. As you progress, you'll find out how to extend vehicle functionalities and keep the code base structure and behavior clean and shiny. Concurrency plays an important role in application design, and you'll learn how to employ a such design patterns with the visualization of thread interaction. The concluding chapters will help you identify and understand anti-pattern utilization in the early stages of development to address refactoring smoothly. The book covers the use of Java 17+ features such as pattern matching, switch cases, and instances of enhancements to enable productivity.

By the end of this book, you'll have gained practical knowledge of design patterns in Java and be able to apply them to address common design problems.

Book Preview (when available)

From the publisher
  • Table of Contents
  • Free chapter (ch 1)

  • Where to get it?
  • Amazon
  • Pactkt

  • Related Websites
    author & internet detective
    Posts: 41855
    Eclipse IDE VI Editor Java
    • Likes 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Early in my career, I read “Design Patterns: Elements of Reusable Object-Oriented Software.” This book is often known as GoF (Gang of Four) after the four authors: Gamma, Helm, Johnson, and Vlissides). This was an excellent book and I referenced it heavily. The patterns are still useful to this day. This book was published in 1994. (Soon we can wish it a happy 30th birthday!).  In a fun coincidence, GoF is about the same age as Java.

    “Practical Design patterns for Java Developers” breaks up the design patterns into the same groups – creational, structural, and behavioral. It adds examples of the features from the JDK itself which is great for linking it to things many Java developers have experienced.It also adds examples of implementing the pattern using modern Java. (Java 17 which was the most recent long term release at the time of the book's presenting.) These new features are used heavily making the book good examples of how to use the language.

    Given that almost 30 years have past, there are more key patterns now. This book covers all the GoF creational patterns and adds object pool, lazy initialization, and dependency injection.  For structural, the book adds the filter, front-controller, marker, module, and twin patterns. For behavioral, the book adds the caching, null object and pipeline patterns.

    The book also covers concurrency patterns and anti-patterns which weren't in GoF. And all that is parts 2 and 3 of the book. Part 1 of the book, gets everyone on the same page. It covers the OOP (object oriented programming), APIE (abstraction, polymorphism, inheritance, and encapsulation) and SOLID (Single responsibility, open-closed, liskov substitution, interface segregation and dependency inversion) terminology in addition to how the JDK is structured.

    All chapters except anti patterns end with review questions (and an appendix with answers) to solidify the information. In addition to the patterns material, I particularly liked the memory graphs in the anti pattern chapter. If you bought a printed book, you get a PDF and color diagrams free. (I didn't try this as a got a review copy). The code is also available on GitHub including the commands to run each example.

    You do need to be comfortable reading Java to make sense of this book. If you aren't there yet, grab another book first and come back to this one. If you are comfortable reading Java, this book is for you!

    I give this book 10 out of 10 horseshoes.

    I received a complementary copy from the publisher in exchange for writing this review.
    Ranch Hand
    Posts: 208
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hello Mr. Miroslav.

    I was going through the free chapter of this book. I have reservations around your description of following features of OOP.

    1. Abstraction: In my understanding abstraction does not mean to extract the common functionality without providing specific implementation. Abstraction refer to abstracting away the complexity or hiding the complexity or the details of implementation from the calling program. That is why the most common example of abstraction given in text books since ages is that of a car. A driver (synonymous with caller progam) is just provided with steering, transmission, gas pedal and breaks. The driver does not need to know the details of how the engine should work. And we can implement abstraction by using access-specifiers. With the help of access specifiers we can ensure to whom and how much details can be exposed. I can make the methods that can be accessed by a calling program public but this public method can in turn call a private method that encloses the complexity.
    Rather the implementation of an interface itself is public because the implementation of an interface i.e the overriding method cannot be more restrictive than overridden method. So i dont understand how interface can help hide complexity from the calling program.

    2. Encapsulation : In my understanding, all the data that has one single reason to change must be enclosed in single construct (class) and thats encapsulation. If my entity defines - then i better encapsulate all publisher info into a single class. Only expose whats required is actually abstraction and not encapsulation as I just mentioned above

    Am I correct or missing something?  I love to be correct but I also enjoy being corrected.
    Consider Paul's rocket mass heater.
      Bookmark Topic Watch Topic
    • New Topic