Is this version of the Abstract Factory Pattern Pretty Backwards?

[Jesse Silverman]

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]

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]

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]

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:

public interface SpellFactory {
  
  public Map<Name, Spell> createSpells();

}

public interface MagicItemFactory {

  public Map<Name, MagicItem> createMagicItems();

}

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

final class Imaginarium {

  private static final Logger LOGGER = LoggerFactory.getLogger(Imaginarium.class);

  private final Map<Name, Spell> spells = new HashMap<>();

  private final Map<Name, MagicItem> magicItems = new HashMap<>();

  private final ServiceLoader<? extends SpellFactory> spellFactoryLoader;

  private final ServiceLoader<? extends MagicItemFactory> magicItemFactoryLoader;

  private boolean loaded;

  Imaginarium(ServiceLoader<? extends SpellFactory> spellFactoryLoader, ServiceLoader<? extends MagicItemFactory> magicItemFactoryLoader) {
    this.spellFactoryLoader     = requireThat("spellFactoryLoader",     spellFactoryLoader,     is(notNullValue()));
    this.magicItemFactoryLoader = requireThat("magicItemFactoryLoader", magicItemFactoryLoader, is(notNullValue()));
  }

  void load() {
    if (loaded)
      throw new IllegalStateException("The imaginarium has already been loaded.");

    spellFactoryLoader.forEach(spellFactory -> {
      spellFactory.createSpells().forEach((name, spell) -> {
        spells.merge(name, spell, (existingSpell, newSpell) -> {
          LOGGER.warn("Another spell named \"{}\" was found. It will be ignored.", name);
          return existingSpell;
        });
      });
    });

    magicItemFactoryLoader.forEach(magicItemFactory -> {
      magicItemFactory.createMagicItems().forEach((name, item) -> {
        magicItems.merge(name, item, (existingItem, newItem) -> {
          LOGGER.warn("Another magic item named \"{}\" was found. It will be ignored.", name);
          return existingItem;
        });
      });
    });
  }

  Map<Name, Spell> spells() {
    if (!loaded)
      throw new IllegalStateException("The imaginarium hasn't been loaded yet.");

    return unmodifiableMap(spells);
  }

  Map<Name, MagicItem> magicItems() {
    if (!loaded)
      throw new IllegalStateException("The imaginarium hasn't been loaded yet.");

    return unmodifiableMap(magicItems);
  }
}

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

module com.example.magic {
  exports com.example.magic;
  exports com.example.magic.spi;

  requires nl.nibsi.util.require;
  requires org.hamcrest;
  requires org.slf4j;

  uses com.example.magic.spi.SpellFactory;
  uses com.example.magic.spi.MagicItemFactory;
}

And here's a plugin that provides an implementation of the abstract factory:

module com.example.magic.plugin {
  requires com.example.magic;

  provides com.example.magic.spi.SpellFactory with com.example.magic.plugin.MySpellFactory;
  provides com.example.magic.spi.MagicItemFactory with com.example.magic.plugin.MyMagicItemFactory;
}

public final class MyMagicItemFactory implements MagicItemFactory {

  @Override
  public Map<Name, MagicItem> createMagicItems() {
    throw new UnsupportedOperationException("Not implemented yet.");
  }
}

public final class MySpellFactory implements SpellFactory {

  @Override
  public Map<Name, Spell> createSpells() {
    throw new UnsupportedOperationException("Not implemented yet.");
  }
}

[Jesse Silverman]

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?

  Imaginarium(ServiceLoader<? extends SpellFactory> spellFactoryLoader, ServiceLoader<? extends MagicItemFactory> magicItemFactoryLoader) {
    this.spellFactoryLoader     = requireThat("spellFactoryLoader",     spellFactoryLoader,     is(notNullValue()));
    this.magicItemFactoryLoader = requireThat("magicItemFactoryLoader", magicItemFactoryLoader, is(notNullValue()));
  }

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]

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?

Imaginarium(
  ServiceLoader<? extends     SpellFactory>     spellFactoryLoader,
  ServiceLoader<? extends MagicItemFactory> magicItemFactoryLoader
) {
  this.spellFactoryLoader = requireThat(
    "spellFactoryLoader", spellFactoryLoader, is(notNullValue())
  );

  this.magicItemFactoryLoader = requireThat(
    "magicItemFactoryLoader", magicItemFactoryLoader, is(notNullValue())
  );
}

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:

requireThat("bodyTemperature", bodyTemperature, is(both(greaterThanOrEqualTo(35.0)).and(lessThan(37.8))));

If you pass the argument 39, it will throw the following exception:
java.lang.IllegalArgumentException:  Expected is (a value equal to or greater than <35.0> and a value less than <37.8>) for parameter 'bodyTemperature', but found <39.0>
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]

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.

/*
 * Copyright (C) 2018 Stephan van Hulst.
 *
 * This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 */

package nl.nibsi.util.require;

import java.util.*;
import java.util.function.*;

import org.hamcrest.Description;
import org.hamcrest.Matcher;
import org.hamcrest.StringDescription;

import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.notNullValue;

/**
 * Utility class for enforcing requirements on method parameters.
 */
public final class Require {

  private Require() { }

  /**
   * Requires that the specified argument that was passed to a method matches a certain condition.
   *
   * @param <T>              the type of the method parameter.
   * @param <X>              the type of exception to throw if the argument doesn't match the condition.
   *
   * @param parameterName    the name of the method parameter being validated.
   * @param argument         the argument that was passed to the parameter with name {@code parameterName}.
   * @param matcher          the condition that {@code argument} must match.
   * @param exceptionFactory a function that creates the exception to throw when {@code matcher} fails.
   *                         The function will be passed the exception message to create the exception with.
   *
   * @return {@code argument}.
   *
   * @throws X if {@code argument} doesn't match the condition described by {@code matcher}.
   */
  public static <T, X extends Throwable> T requireThat(
    String parameterName,
    T argument,
    Matcher<? super T> matcher,
    Function<String, X> exceptionFactory
  ) throws X {
    if (!matcher.matches(argument)) {
      Description description = new StringDescription()
        .appendText("Expected ")
        .appendDescriptionOf(matcher)
        .appendText(String.format(" for parameter '%s', but found ", parameterName))
        .appendValue(argument);

      throw exceptionFactory.apply(description.toString());
    }

    return argument;
  }

  /**
   * Requires that the specified argument that was passed to a method matches a certain condition.
   *
   * Calling this method is is equivalent to calling
   * {@code requireThat(parameterName, argument, matcher, IllegalArgumentException::new)}.
   *
   * @param <T>           the type of the method parameter.
   *
   * @param parameterName the name of the method parameter being validated.
   * @param argument      the argument that was passed to the parameter with name {@code parameterName}.
   * @param matcher       the condition that {@code argument} must match.
   *
   * @return {@code argument}.
   *
   * @throws IllegalArgumentException if {@code argument} doesn't match the condition described by {@code matcher}.
   */
  public static <T> T requireThat(String parameterName, T argument, Matcher<? super T> matcher) {
    return requireThat(parameterName, argument, matcher, IllegalArgumentException::new);
  }

  /**
   * Requires that the specified index that was passed to a method matches a certain condition.
   *
   * Calling this method is is equivalent to calling
   * {@code requireThat(parameterName, index, matcher, IndexOutOfBoundsException::new)}.
   *
   * @param <T>           the type of the method parameter.
   *
   * @param parameterName the name of the method parameter being validated.
   * @param index         the index that was passed to the parameter with name {@code parameterName}.
   * @param matcher       the condition that {@code index} must match.
   *
   * @return {@code index}.
   *
   * @throws IndexOutOfBoundsException if {@code index} doesn't match the condition described by {@code matcher}.
   */
  public static <T> T requireThatIndex(String parameterName, T index, Matcher<? super T> matcher) {
    return requireThat(parameterName, index, matcher, IndexOutOfBoundsException::new);
  }

  /**
   * Copies the specified collection that was passed to a method to a new list
   * and requires that the list matches a certain condition.
   *
   * @param <E>           the type of the collection elements.
   *
   * @param parameterName the name of the method parameter being validated.
   * @param argument      the collection that was passed to the parameter with name {@code parameterName}.
   * @param matcher       the condition that the copy of {@code argument} must match.
   *
   * @return a new list that is a copy of {@code argument}.
   *
   * @throws IllegalArgumentException if the copy of {@code argument} doesn't match
   *                                  the condition described by {@code matcher}.
   */
  public static <E> List<E> copyToListAndRequireThat(
    String parameterName,
    Collection<? extends E> argument,
    Matcher<? super List<E>> matcher
  ) {
    requireThat(parameterName, argument, is(notNullValue()));
    return requireThat(parameterName, new ArrayList<>(argument), matcher);
  }

  /**
   * Copies the specified collection that was passed to a method to a new navigable set
   * and requires that the set matches a certain condition.
   *
   * @param <E>           the type of the collection elements.
   *
   * @param parameterName the name of the method parameter being validated.
   * @param argument      the collection that was passed to the parameter with name {@code parameterName}.
   * @param matcher       the condition that the copy of {@code argument} must match.
   *
   * @return a new navigable set that is a copy of {@code argument}, discarding duplicate elements.
   *
   * @throws IllegalArgumentException if the copy of {@code argument} doesn't match
   *                                  the condition described by {@code matcher}.
   */
  public static <E> NavigableSet<E> copyToNavigableSetAndRequireThat(
    String parameterName,
    Collection<? extends E> argument,
    Matcher<? super Set<E>> matcher
  ) {
    requireThat(parameterName, argument, is(notNullValue()));

    var copy = new LinkedHashSet<E>(argument);
    requireThat(parameterName, copy, matcher);

    return new TreeSet<>(copy);
  }
}

/*
 * Copyright (C) 2018 Stephan van Hulst.
 *
 * This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 */

package nl.nibsi.util.matchers;

import java.util.*;
import java.util.function.*;

import org.hamcrest.CustomTypeSafeMatcher;
import org.hamcrest.Matcher;

import static org.hamcrest.Matchers.both;
import static org.hamcrest.Matchers.emptyString;
import static org.hamcrest.Matchers.hasItem;
import static org.hamcrest.Matchers.hasItemInArray;
import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.not;
import static org.hamcrest.Matchers.notNullValue;
import static org.hamcrest.Matchers.nullValue;

/**
 * Utility class to create common matchers.
 */
public final class Matchers {

  private Matchers() { }

  /**
   * Creates a type-safe matcher from a description and a predicate.
   *
   * @param <T>         the type of the argument that will be matched.
   *
   * @param description a description of the argument that will be matched.
   * @param predicate   a predicate that will be applied to the argument when it is matched.
   *
   * @return a matcher with the given {@code description} that will successfully match an argument
   *         if the {@code predicate} on that argument returns {@code true}.
   */
  public static <T> Matcher<T> createTypeSafeMatcher(String description, Predicate<? super T> predicate) {
    return new CustomTypeSafeMatcher<T>(description) {
      @Override
      protected boolean matchesSafely(T item) {
        return predicate.test(item);
      }
    };
  }

  /**
   * Returns a matcher that matches when the examined string is stripped.
   *
   * @return a matcher that returns {@code true} when the examined string doesn't
   *         start or end with whitespace characters.
   */
  public static Matcher<String> strippedString() {
    return createTypeSafeMatcher(
      "a stripped string",
      string -> string.strip().equals(string)
    );
  }

  /**
   * Returns a matcher that matches when the examined string is stripped and non-empty.
   *
   * @return a matcher that returns {@code true} when the examined string doesn't
   *         start or end with whitespace characters, and also isn't empty.
   */
  public static Matcher<String> nonEmptyStrippedString() {
    return both(strippedString()).and(not(emptyString()));
  }

  /**
   * Returns a matcher that matches when the examined collection does not contain {@code null}.
   *
   * @param <E> the element type of the collection that will be matched.
   *
   * @return a matcher that returns {@code true} when the examined collection does not contain {@code null}.
   */
  public static <E> Matcher<Collection<E>> collectionWithoutNullValue() {
    return org.hamcrest.Matchers.<Collection<E>>both(is(notNullValue())).and(not(hasItem(nullValue())));
  }

  /**
   * Returns a matcher that matches when the examined array does not contain {@code null}.
   *
   * @param <E> the element type of the array that will be matched.
   *
   * @return a matcher that returns {@code true} when the examined array does not contain {@code null}.
   */
  public static <E> Matcher<E[]> arrayWithoutNullValue() {
    return org.hamcrest.Matchers.<E[]>both(is(notNullValue())).and(not(hasItemInArray(nullValue())));
  }
}

[Jesse Silverman]

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]

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!

final class Farrier {

  private final HorseShoeFactory horseShoeFactory;

  ...

  void fitHorseShoes(Horse horse) {
    horse.hooves().forEach(hoof -> {
      var horseShoe = horseShoeFactory.createHorseShoe();
      hoof.fitHorseShoe(horseShoe);
    });
  }
}

final class Stable {

  public static void main(String... args) {
    var horse      = new Horse("Seabiscuit");
    var blacksmith = new Blacksmith("Schmidty & Sons");
    var farrier    = new Farrier("Hank's Hoofcare", blacksmith);
    
    farrier.fitHorseShoes(horse);
  }
}

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.

[Jesse Silverman]

I love your example and in parallel have now totally got how the "Factory of Factories" concept is at most totally incidental to the true concept of Abstract Factory, and in fact, is very often not even present!  Explicit or framework injection of the concrete factory is actually significantly more likely.

Now, I will mention this next thing because I also do it, and some people mention it to me as a potential problem.

The word farrier is what many people in the United States would call an "SAT word", dictionary.com describes it as college level. (Meaning University, dictionary.com defaults to American English).

Separately, when talking about the evolution of languages over a period of centuries (yes, I love both philology and linguistics), the classical example of changing levels of familiarity with different word families in populations is very often those related to horses.

That is to say, a University English Professor in 2021 might think that they are very literate and eloquent with a large vocabulary of many thousands of words, and a farm-hand from 1821 is illiterate, ignorant and ineloquent, with a vocabulary consisting of a few thousand words.  However, where that supposedly ignorant farm-hand knew between 100 and 200 terms relating to horses, our good Professor will be hard-pressed to come up with more than three or four that they actually know the definition of.

I know we are sharing information on a Ranch, but we have many City Slickers amongst us, and even among those with experience with horses, easily upwards of a dozen first languages.

Lastly, while we all have access to good, free, online dictionaries, many readers might be confused when they look it up to see farrier defined not as "a shoer of horses" but "a blacksmith".  This is the fault of the dictionaries, but could easily lead someone to getting lost in the example, they just looked it up and saw "farrier == blacksmith".

I would therefore avoid the term "farrier" in tutorial examples meant for our general audience.

I was once asked by a supervisor to write all tutorial materials restricted to a sixth-grade reading level only.  They intended to enforce it.  As I had plenty of feedback from the audience I was writing for that they found my materials both enjoyable and understandable, I thought this was unnecessary and insulting to all parties.

The concept still is a valid one, however.  When attempting to teach new vocabulary and concepts, we should restrict ourselves to domains that everyone is familiar with for pedagogical purposes, learning new words like farrier at the same time may be sub-optimal.

I personally loved the example, however.

[Jesse Silverman]

After the side-trip into the world of Equestrian Philology, back to the concept at hand.

I do think it would be nice to have one or more sources of free, high-quality, Design Patterns in Java material to refer confused Ranchers to.  Towards this end I had been cleaning up our Design Pattern Links page, first with an eye towards updating or deleting dead links, then with attention to "What are the best sources that we never mentioned because they were too new?"

There are several sites that have received a lot of love and caring attention by knowledgeable people with high aptitude for explaining complex topics clearly.

I am a little "Zoomed-In" on the Creational Patterns right now because that is just the order I've been studying them in.

The better ones all begin with a review of good Object-Oriented Design Principles, as a reminder of what kinds of goals we are looking at Design Patterns to help us succeed in attaining in the first place.

One of the most basic of these is "Coding to Interface, rather than Implementation".

I am now feeling that those who jump right to "Abstract Factory Pattern" == "Factory of Factories" are failing to notice and apply their own advice.

They are immediately hard-coding an implementation of the pattern at the point where they should be working with the abstraction so that readers/viewers understand what is essential about the concept.

I believe that many sites that do this are nevertheless invaluable resources in general, and possibly could have excellent presentations that take someone from zero knowledge to great understanding of other patterns quickly and enjoyably.

But in itself, it is probably a Red Flag, if only a small one.

I hereby consider it a "Green Flag" that our friend behind this site:
https://w3sdesign.com/

Explains the heck out of "Abstract Factory" without ever using the term "Factory of Factories" even once.

While this one also never uses the term "Factory of Factories" but tries to explain "Abstract Factory" without reference to the ability to create a compatible family of inter-related products, which the best sources seem to consider an important part of the spirit of the pattern:
https://howtodoinjava.com/design-patterns/creational/abstract-factory-pattern-in-java/

Also no reference to the term "Factory of Factories", nor hard-coding of the concept without naming it:
https://sourcemaking.com/design_patterns/abstract_factory

Same here:
https://refactoring.guru/design-patterns/abstract-factory

Our friend here does indeed show one without naming it, but does NOT imply that it is central to the concept of the Abstract Factory Design Pattern, but merely incidental in the example:
https://java-design-patterns.com/patterns/abstract-factory/

I am going to attempt to not read too much into the relative pedagogical quality of these competing sources based solely on their explanation of a single creational pattern, but it is probably a decent clue.

[Jesse Silverman]

I've had some time to reconsider.

Maybe it is because the browser Icon for our CodeRanch tabs is a horseshoe, maybe it is because we measure the quality of books that we review in horseshoes, maybe it is because horseshoe crabs are both so ancient and medically important for humans.

But I am beginning to think that if Ranchers don't know whether a farrier is a blacksmith or someone that shoes horses, it probably behooves them to learn.

It is still considered a "University-Level" vocabulary word, tho.

[Stephan van Hulst]

To be fair, the only reason I know the word "Farrier" is because I occasionally play the Civilization games and "Farriery" is a technology you can research fairly early on.

[Paul Clapham]

Jesse Silverman wrote:...behooves...

Nice!