0

One of the Dart criticized features are named and factory constructors.

There are opinions (from dependency injection people), that constructors should be simple and just assign some fields and the object graph creation is a responsibility of factories.

There are also some argues against the static methods.

It seems, that Dart constructors bring complexity to constructors. You can not even have a lot of named constructors to create the object in a various ways, you can even have a static factory supposed to construct object of other type than the class it is in.

So, what is the philosophy of Dart and how does it relate (or respond) to the Dependency Injection and no-static state philosophies?

Improve this question
4
  • 1
    According to article you linked, Functional code can't be tested, and that's untrue. Quote: "The basic issue with static methods is they are procedural code. I have no idea how to unit-test procedural code. Unit-testing assumes that I can instantiate a piece of my application in isolation. During the instantiation I wire the dependencies with mocks/friendlies which replace the real dependencies. With procedural programing there is nothing to “wire” since there are no objects, the code and data are separate."
    – David Sergey
    Aug 12, 2013 at 8:35
  • People think static methods are untestable because they do dumb things with them like manipulate static state. If you keep them immutable, static methods are the most testable of all.
    – Robert Harvey
    Aug 12, 2013 at 15:56
  • @RobertHarvey people think static methods are untestable, because you can't use mocks with code, which use static methods.
    – OZ_
    Feb 14, 2015 at 19:59
  • @OZ_: Purely functional code must not be testable at all, then.
    – Robert Harvey
    Feb 14, 2015 at 22:23

1 Answer 1

Reset to default
1

Constructors are where you should construct things. That's why they are so named :)

The alternative to constructing everything in the constructor is that you will have a half-constructed object that you then rely on the rest of the program to handle well until its had its properties initialised. This makes things more complicated than they should be - compared to always having a fully constructed object. Martin Fowler talk about this.

I'm not sure about Dart's philosophy of constructing - if you can't overload the constructor for different cases, it sounds a bit limiting.

Improve this answer
5
  • But if you instantiate new (other) objects in constructor, you can't test this code.
    – OZ_
    Feb 14, 2015 at 20:02
  • @OZ_ but how do you test an object's created correctly without accessing its state and testing those accessor methods too? Don't let yourself be fooled by the tools that generate single method stubs for tests, a unit test can be more than just a method, as Fowler says. Testing a class as a unit allows you to create how-to-use documentation too, something that a single method test is often useless at.
    – gbjbaanb
    Feb 15, 2015 at 13:15
  • it's funny how you've imagined that I use some tools and even ask me to not use them, when it's only your imagination :) All my tests are hand-written, don't let be fooled by your imagination.
    – OZ_
    Feb 15, 2015 at 17:13
  • @OZ_ they you should have no problem testing a class and its dependants, so I don't see why you asked the original question.
    – gbjbaanb
    Feb 15, 2015 at 20:03
  • It wasn't me :)
    – OZ_
    Feb 15, 2015 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.