• 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 ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Is this version of the Abstract Factory Pattern Pretty Backwards?

 
Jesse Silverman
Saloon Keeper
Posts: 1601
51
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While there are no one right implementation of any pattern in any language, there are definitely some wrong ones.

I actually like this guy a lot and thought I would be mentioning him only in a positive light when someone asks a question that I can help on but there is more and better information in one of his tutorials.  That will still happen at some point.

But right now I was surveying how different people I've learned other stuff from decide to interpret some of the Creational GOF design patterns, and most of the ones I am seeing for both Prototype and Builder are a mess.

I don't think this gets the point of "Why we want the Abstract Factory Pattern" (or if it does then I don't):
https://kkjavatutorials.com/abstract-factory-pattern-in-java/

What I dislike most is that they are coming up with concrete factories that have every single thing we could want to change built-in.

I understand that having too many parameters on your calls to those factories is sub-optimal, but passing everything you might want to change in different invocations for getInstance() into the constructor for the factory itself seems wrong to me.

Someone else explained that the magic of the Abstract Factory pattern is that you can have several different factories, each of which can have multiple methods for getting you let's say a compatible device, headset or charger from that same factory.  I've seen that in like two examples.

Other places seem to agree that its spirit is "a factory for factories" but often diverge wildly on what that looks like in UML or code.

This is sort of a factory for factories, but way too much gets baked in to the definition of a concrete factory to make sense to me.
 
Paul Clapham
Marshal
Posts: 26909
82
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For me, Java's XML processing has a few examples of the Abstract Factory Pattern.

For example consider SAXParserFactory. It has no fewer than six static methods whose purpose is to produce a SAXParserFactory object, although they come in pairs, one for namespace-aware parsers and the other for namespace-oblivious parsers. So there's really three versions. One creates a SAXParserFactory from the system default, a second creates one by looking at a predefined system property which provides a class name, and the third creates one when given the class name directly. This structure is therefore an Abstract Factory, since its purpose is to produce a concrete factory.

Then once you have a SAXParserFactory, you call newSAXParser and it gives you the parser to apply to your XML document.

You can see the whole list of factories in the API documentation for the java.xml module -- there's several there which I never heard of.

History: XML was born in 1998, about the same time as Java. So early versions of Java didn't include XML parsing code, and therefore other people wrote their own XML parsers and distributed them widely. Then when Java chose to include XML parsers, starting about Java 5, they included the Abstract Factory which allowed one to continue using the parsers which came from those other people. (Which were often better than Java's system default.)
 
Jesse Silverman
Saloon Keeper
Posts: 1601
51
Eclipse IDE Postgres Database C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The same guy I complained about, in his next tutorial and video, uses:
DocumentBuilderFactory, TransformerFactory and XPathFactory as examples of Abstract Factory Design Pattern in the JDK.

I think I see some of the stuff you are talking about here:
https://docs.oracle.com/en/java/javase/17/docs/api/java.xml/module-summary.html#LookupMechanism

I still think the example linked is confused, but it is possible I am.
There are legitimately different takes on implementation details, yet some things that go way off the path...
 
Stephan van Hulst
Saloon Keeper
Posts: 13366
295
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The concept of "factory of factories" is definitely NOT what the abstract factory pattern is about.

It is true that many applications will use a static factory method to provide an abstract factory, but this is actually not part of the pattern, and does nothing to demonstrate the power of the abstract factory pattern.

The name of the pattern really says it all. You have an abstract class (or preferentially, an interface) that contains methods to create instances of another type. THAT'S IT. The application uses the abstract factory to create instances with, and the client of the application provides the factory.

Let's say you're making a role playing game and you want to have magical items that can cast spells that have effects on the world. You program the world and the effects that spells can have on it, but you don't provide the spells or the items. You want to add these in a separate module, or have modders add their own magical items to the game. Here are two abstract factories:

The application might compile a repository of all available items and spells in the game:

You can now very easily load spells and magic items from other modules:

And here's a plugin that provides an implementation of the abstract factory:
 
Jesse Silverman
Saloon Keeper
Posts: 1601
51
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Excellent, and I will be spending some time looking at this, no doubt.

One side issue, I am trying to come up with a better personal standard of avoiding Very Long Lines in Java.  I would normally adapt to that of whoever is paying my salary, or the Professor, because consistency breeds familiarity...or something like that.

How might you format the constructor definition below in an environment that restricted or discourages lines longer than 100 chars?  80 chars?



I am moderately familiar with:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Objects.html#requireNonNull(T,java.lang.String)

But unfortunately not the requireThat( , , ) idiom used there.  What's that bit about?
 
Stephan van Hulst
Saloon Keeper
Posts: 13366
295
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:How might you format the constructor definition below in an environment that restricted or discourages lines longer than 100 chars?  80 chars?




But unfortunately not the requireThat( , , ) idiom used there.  What's that bit about?


It's from a library I wrote for myself, that I never officially publicized. I got tired of writing exception messages when validating method and constructor parameters. You use Hamcrest matchers to describe parameters fluently, and the requireThat() method uses the matcher to spit out a detailed exception message when the argument doesn't match the requirement.

For instance, say you wrote the following statement:

If you pass the argument 39, it will throw the following exception:

If there's enough interest, I might be convinced to make an official release out of my library and put it in Maven Central.
 
Stephan van Hulst
Saloon Keeper
Posts: 13366
295
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's the code if you want it, it's quite simple. Feel free to use it in your projects, as long as you leave the copyright notice and attribution, and adhere to the MPL licence.


 
Jesse Silverman
Saloon Keeper
Posts: 1601
51
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:The concept of "factory of factories" is definitely NOT what the abstract factory pattern is about.
It is true that many applications will use a static factory method to provide an abstract factory, but this is actually not part of the pattern, and does nothing to demonstrate the power of the abstract factory pattern.

The name of the pattern really says it all. You have an abstract class (or preferentially, an interface) that contains methods to create instances of another type. THAT'S IT. The application uses the abstract factory to create instances with, and the client of the application provides the factory.



Hi Stephan:

I am still studying your reply, which contains a LOT.

I will note that it seems that a high percentage of sites describing the abstract factory pattern jump right to "factory of factories".
For example, this site which generally seems pretty solid:

https://www.programcreek.com/2013/02/java-design-pattern-abstract-factory/

Does this one get it any better?

https://howtodoinjava.com/design-patterns/creational/abstract-factory-pattern-in-java/

Many of the sites with comments allowed seem to have many comments "This is not really a good example of Design Pattern X", often with links to other sites.  Particularly when it comes to subtleties of the Creational Patterns.

This does make studying this topic a little tricky.

I have seen presenters who say "Everyone should have a copy of Head First Design Patterns, go buy it!" and proceed to use different examples for several of them that they find confusing, misleading or otherwise sub-optimal as presented in the book.  At least they explain why they are presenting it differently.

 
Stephan van Hulst
Saloon Keeper
Posts: 13366
295
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I understand where the notion of "factory of factories" comes from. Most tutorials start by explaining what a factory method is. Then when they introduce the concept of the abstract factory pattern, they call back to the chapter on factory methods, and write a factory method that returns an instance of a factory class. Wow, a factory of factories!

What gets me angry is that they draw attention to the factory method, while the method that creates the factory is the least important thing about the pattern. You don't even need one!

In this excellent equestrian example, a farrier requires the services of a contracted horse shoe factory to get the horse shoes necessary to care for a horse's hoofs. It doesn't care how the horse shoes are made, just that they are made. The horse shoe factory is implemented by a blacksmith.

Shock and awe, we managed to implement and use the abstract factory pattern without writing a factory method that creates instances of HorseShoeFactory.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic