9
dUcKtYpEd
31d

I've never been the biggest fan of overcomplicated patterns that lead to leaky abstraction but how in the hell did we ever agree on abstract factories being a thing.

Comments
  • 4
    Never came across a situation I needed a family of related objects where those objects must all be created a specific way for the family.

    Maybe if my program was modelling the royal family
  • 5
    Every time I see an AbstractFactory I think, what we really need here, is an AbstractAbstractFactoryFactory.
  • 2
    Who do you mean, we? I never agreed :)
  • 1
    @craig939393 haha my thoughts exactly. LIke maybe if its fresh on my mind, i would find a use case but theres no way the average dev is going to look at this and not think wtf. Its confusing enough with teh easiest examples. Id hate to see it applied to a complex real life scenario like Oauth clients.
  • 2
    @dUcKtYpEd There could well be a good reason, but it feels like if you need to care about how your objects are created so that they can interact together properly, I don't understand how that can conform with the inversion of control principle. By definition we don't care about implementation details...

    Anyway open to someone correcting us.
  • 0
    @craig939393 im definitely waiting for someone to school me any minute now. I just hate things being overly abstracted. We emphasize SCREAMING architecture, well nothing about 10 interfaces to fulfill one use case screams anything to me. More of an interface puzzle that the next guy has to spend a week putting together.
  • 1
    AbstractFactoryProxyClassBeanFactory
  • 2
    @dUcKtYpEd I had to work with code where there were trivial mappers for trivial models of different layers, created by factories, which in turn were created by services, which were created by some dependency injection abstraction. All of the involved classes had their own useless interface.

    This has led me to hate overly abstracted code, too.
  • 1
    @Lensflare it makes total sense when on paper and maybe in a time before the concept of breaking repos up into easily digestible services. But almost everytime i see these practices applied to real life scenarios, its a mess.
  • 1
    I mean, if you're creating a framework for *someone else* to use, Abstract Factories do find their uses... you can hide common factory functionality in them and essentially give the "user" bunch of stuff and structure for free, while giving him the power to implement his own object creation... I don't know, say a game engine

    AbstractObjectFactory might just be one of many factories used to initialize objects from a map file. PlayerFactory, MonsterFactory, NPCFactory..

    they can all extend the same Abstract factory... but why use an abstract factory instead of an interface? well because you don't want to implement boilerplate stuff that the engine or you might appreciate! maybe you'll just implement create(Item) but the abstraction does create(List<Item>) for you now, or maybe it does some caching on the backscene, and keeps it encapsulated per-factory...

    I'm sure there's a good legit reason to use it, it's just gonna be rare
  • 0
    I use them. I have a project where the entire functionality of the application is handled with plugins, the main application is linked to the plugin library, it calls load plugins and as each plugin is loaded, it’s dependencies are figured out and everything loaded in order.

    Abstract factories come into play because plugins don’t know anything about other plugins, apart from abstract classes.

    Let’s say I have an IEditor, the core plugin provides an editor manager which manages open editors, it knows nothing about editors only that they conform to IEditor. Now we need to create editors, the core plugin can’t instantiate an editor because it doesn’t know anything about a class that implements IEditor.

    So, a plugin that provides an IEditor also provides an IEditorFactory, that’s capable of creating specific editors. After initalisation, the core finds all IEditorFactories and can present these to the user, so they can select file/New Text file.. or New Database...

    Core knows nothing about the implementation of these, it doesn’t need to, all it needs to know is how to interact with IEditorFactory and IEditor. An IEditorFactory might provide a widget for configuring a new file, when the user selects new file... then the widget is shown by core to allow the user to set the appropriate information.
  • 0
    @fizzyade Well that sounds more like an interface for a factory than an abstract factory. An abstract factory would be as the name says an abstract class from which other factories inherit.
  • 0
    That’s exactly what it is, everything is defined as pure virtual, factories inherit IEditorFactory and implement those methods.
  • 0
    @TheSilent unless we are talking a cross purposes. I am very tired though not sleeping last night and am fuelled by morphine! :p
  • 0
    @TheSilent @fizzyade I think you may not realise that an abstract factory is not just a template method pattern applied to a factory. It's about creating a family of related objects.
  • 0
  • 0
    @fizzyade that makes sense. In your case it sounds like your implementing clean architecture which is also what im slowly (emphasis on slow) progressing towards understanding.
  • 2
    @craig939393 he was saying the nature of his plugins allow for the creation of factories for each branch of plugins. Its still confusing to think about which i guess is kinda my point in all of this. Like dealing with nomads. Even the OGs I know of functional land kinda laugh about truly confusing it eventually gets.
  • 0
    I thinkt eh biggest thing for me is ill never have this unique set of relationships where several factories create products implementing the same interface. Its rare that happens. My products are usually different in many ways. Even trying to apply the logic to the oauth we replicate across google and office. It eventually still separates in logic too much to shove under this web of abstractions
  • 0
    @dUcKtYpEd the source is on github under the project repo pingnoo (I can’t post links here yet) so you can see the architecture of it.

    I have spent the evening fixing memory leaks, it currently crashes on exit if you create an editor, I haven’t got round to fixing that as it’s an error I just introduced into it during my cleanup.

    I use this architecture because it allows me a lot of flexibility, I first implemented it on some commercial software for our next generation product, that was 10 years ago and it’s still as flexible now as it was then, not hit any issues with new functionally because nothing is set in stone, it’s turtles (interfaces) all the way down.
Add Comment