(Video, German) Object-Oriented Domain-Driven Design Talk

5 thoughts on “(Video, German) Object-Oriented Domain-Driven Design Talk

  1. Great talk!
    Regarding your Password example, what I really don’t like, is the `generateStrongPassword()` static method. I understand, it should be a factory, but static methods just don’t belong to OOP.
    Wouldn’t be a better design just to have two classes `StrongPassword` and `WeakPassword`, implementing a Password interface? You get rid of the strange static method and `isWeak`, `isStrong` become unnecessary as well…

    Liked by 1 person

    1. I understand and share your aversion to static methods.

      Yes, it would be a better design to have a factory object, perhaps called `PasswordGenerator` or some such with `generateWeakPassword()` and `generateStrongPassword()`.

      Having `StrongPassword` and `WeakPassword` is also a good idea, since the example defines `isStrong()` and `isWeak()` as business methods, so the two would actually behave differently. Having the actual generating of passwords in the constructor is acceptable in this case, but more complicated logic would definitely need a factory of some kind.

      Thanks for the excellent observations and ideas!

      Just as a sidenote, I am not against some static methods, like `Optional.of(…)` and things like that. Those are conceptually constructors but with fancy syntax. Also, sometimes necessary in Java because of type erasure.

      Like

      1. Static factory methods in such general classes as Optional is okay, even if we can think about more OO approach like a NullableOptional class etc. Unfortunately we can’t forget Java is no pure OO language at all and it’s a market strategy to use such concepts, procedural programmers are familiar with, because they have majority ­čÖé
        Anyway, I would love to see this talk in English or at least as an article, for much bigger impact it could have.
        I really appreciate your work!

        Like

      2. I don’t see the benefit of having two separate objects here. “isStrong()” and “isWeak()” should be sufficient on “Password” to determine its strength. We only need to encapsulate whatever is changing and the only thing different between the two is the underlying String type that represents the actual password.

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s