Is using static-typing the solution to domain-driven design and decreasing the number of errors?

Question

We are using PHP (a dynamically-typed language) in our project. However, I have found my colleagues asking questions such as https://stackoverflow.com/questions/20438322/modeling-a-binary-relationship-between-two-types.

I’m feeling like we have a paranoia that we are going to get unexpected errors (E.G. if you look at that example question, you will see that the poster is asking how to ensure that a like does not get initialized for a Person), and we are using static-typing (something that doesn't exist in PHP) along with unit tests to help ourselves rest easy at night. :-)

Now, the thing that tells me our approach is wrong is the number of big websites written using dynamically-typed languages: Google uses Python extensively, Facebook is written using PHP, Twitter and GoodReads are written using Ruby. So what I feel is that web applications—at the very least—are moving toward dynamically-typed languages.

However, no matter how I try to comprehend this, i can’t. Don’t these guys have trouble comprehending the domain? Don’t they have problems that arise when using dynamically-typed languages (E.G. “Property whatever is not defined on this object.”)? If they do, how do they deal with those while keeping the agility that comes with using dynamically-typed languages?

Answer 1

how do they deal with those while keeping the agility that comes with using dynamically-typed languages?

Many people would argue if you really want to be agile (i.e. comfortably change your code often), you need unit testing.

Relying on the compiler to make sure: 2+2=Number is really just a false sense of security. So if you're going to take the trouble to write a unit test, why not be a little more accurate and test: 2+2=4?

With Domain Driven Design, you're dealing with much more complicated problems and objects (That's typically why it is used.) that will barely be managed by type checking alone. Consider writing some tests.

Answer 2

You're over-thinking the differences between interpreted and compiled languages, and not really realizing the benefit of dynamic object creation and object oriented design.

Assuming that you had a situation similar to the question linked, where a user could like a Business but not a Person, you would be better off not allowing a direct instantiation of a distinct Like object, but instead making the execution point a method on the Business object.

That is, instead of:

//Like a business
$thisBiz = ...;
$myLike = new Like[$thisBiz];

You could have:

//Like a business
$thisBiz = ...;
$myLike = $thisBiz.Like();

If a latter programmer tries calling a method of an object that doesn't possess it, they'll get a runtime error, and a good IDE will catch it at design-time as well. Which is exactly what happens in a compiled language with static types.

The real power of dynamic typing is when you want to make a change to how things work. If Like is an object that takes a business as a parameter, and you want to allow people to be liked as well, you may wind up having to make a second Like constructor, or even a separate class, or even redefine it to accept a Thing parent that both Businesss and Person can be CAST to. Or you could just add the method to the Person class and be done with it.