Hacker News new | ask | show | jobs
by masklinn 5144 days ago
> It's possible to implement it as instance method

It makes no sense, if you're doing that you've switched to full-blown factories (abstracts or builders), you're not using factory methods anymore.

> Whether it be a static factory method or an instance method, fact is you need a reference to an implementation (class). In dart, you can do

> List someListInstance = new List();

> where List is an interface. There is none class needed in your consuming code, none.

That's got nothing to do with factories, or interfaces.

> You need _some_ class (whether it be a static method on it, or an instance method) to get a new instance of the interface.

You always need a class, even in Dart there has to be a default List implementation of some sort which can be called (and has to be specified on the interface, it's not like you can even provide your own default implementation of a third party's interface). As to the calling code needing to know about that one concrete implementation:

    abstract class Foo {
        public static Foo foo() {
            return new FooImpl();
        }

        public abstract void printFoo();
    }

    class FooImpl extends Foo {
        public void printFoo() {
            System.out.println("I am FooImpl");
        }
    }

    class Main {
        public static void main(String[] args) {
            Foo foo = Foo.foo();
            foo.printFoo();
        }
    }
Oh look at that, the calling code does not know anything about FooImpl.

> Named constructors felt very liberating when working with Dart.

Yeah, that's so much more liberating than:

    List.from([instance1, instance2]);
Wait, no it's not.
1 comments
generateui 5144 days ago
Your consuming code is tied to Foo. In dart, the consuming code only needs tying up to the interface.

> You always need a class

Nope. That's the whole point which I am trying to communicate: you do not need a reference to a class to get the instance of the interface from, as you confirm later on:

> As to the calling code needing to know about that one concrete implementation:

My personal feeling of liberation comes from the fact that the code is simpler and more clear. The non-coupling is nice, but can be achieved with dependency injection too: the point is the transfer of characters into a mental model which is more efficient with the named constructors/factory constructors.

link
masklinn 5144 days ago
> Your consuming code is tied to Foo. In dart, the consuming code only needs tying up to the interface.

Foo is an abstract class, which is the exact same thing.

> Nope. That's the whole point which I am trying to communicate: you do not need a reference to a class to get the instance of the interface from

Neither do you in the code I posted, can you bloody read?

> My personal feeling of liberation comes from the fact that the code is simpler and more clear.

You'll have to give actual examples of that, because I've not seen it so far.

> the point is the transfer of characters into a mental model which is more efficient with the named constructors/factory constructors.

This phrase doesn't even make sense, what "transfer of characters" are you talking about, and how is it more efficient for the user to type more? (named constructors only add ceremony to factory methods) (I'm not even going to talk about factory constructors again, they're a band-aid on the self-inflicted wound of stupid java-style constructors)

link