5 thoughts on “(Video, German) Object-Oriented Domain-Driven Design Talk”
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…
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.
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!
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.
The New Java Developer 
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…
LikeLiked by 1 person
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.
LikeLike
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!
LikeLike
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.
LikeLike
Have you considered adding English captions? I think it would be quite useful for a lot of people (me included :)).
LikeLike