Hi @chazwatkins. If the intent is to virtualize Application's inner *Factory classes, then should their public methods be marked with the virtual modifier too, otherwise, one cannot override the existing functionality, if desired.

@stohn777 - Good call. I'll make the public methods virtual as well.

Hi @chazwatkins. If the intent is to virtualize Application's inner *Factory classes, then should their public methods be marked with the virtual modifier too, otherwise, one cannot override the existing functionality, if desired.

Hey @stohn777, I updated the public and protected methods to be virtual for extension.

@chazwatkins I have been thinking about this PR for the past few weeks. I have a concern about the value of making Application and the subclasses virtual. My concern is that to make it virtual means that another class would extend (please forgive my 1st grade thought here - no offense is intended - just trying to draw picture). But in extending to another "application" class, wouldn't you be saying "all development in this org now must use this new FooBarApplication class everywhere instead of the established Application class? Part of the power of the FFLIB Apex Commons framework (and subsequently AT4DX) is that it centralizes every aspect of Service, Selector, Domain, and UOW object creation to an agreed upon set of four distinct application factories (not one). Every developer in the org knows to use the Application.Service, Application.Selector, Application.Domain, and Application.UnitOfWork factories. It is that "agreed upon convention" that increases the value of the patterns, and increases the adoption.

I guess my question becomes "What are some use cases that you believe are worth the disruption of changing the established pattern of using Application class?"