You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge branch 'feature/TopicFactory-Create-parameters' into develop
Previously, there were two overloads for the `TopicFactory.Create()` method which used competing parameter orders. Not only did the parameter order compete within the overloads, but it also competed with the corresponding parameter order of the `Topic` constructor. This is confusing.
To mitigate this, I consolidated the two `Create()` overloads and, as part of that process, standardized the parameter order. This allows the logic between these methods to be centralized, and maintains consistency across the application.
Technically, this is a breaking change. In practice, however, the vast majority of callers to `Create()` never pass an `Id` and, therefore, won't notice the change. The only production code that's expected to use this overload are concrete implementations of `ITopicRepository.Load()` which interact directly with a persistence store (i.e., not abstract base classes or decorators or test stubs). The only concrete implementation we have is `SqlTopicRepository`, and it actually loads the `parent` topic separately, and thus doesn't break with this change.
That said, a lot of non-production code breaks with this change. Namely, it's common for unit tests—and test doubles—to generate topics using the `TopicFactory` that have both a `parent` (in order to simulate a topic graph) and an `id` (in order to simulate a saved entity, even though the number is arbitrary). As such, the unit tests needed to be updated to reflect this change.
Outside of that, this isn't _expected_ to impact any third-party implementations.
0 commit comments