Closed IAmStoxe closed 7 years ago
Hi. Can you show an example of when it's a problem? Are you trying to make a mock instance of video info? The reason its constructor (along with other models) is internal is to make it immutable once it leaves YoutubeExplode's boundary. The properties have internal setters because they are set from multiple places inside the library.
Good example is serialization. Deserializing VideoInfo will be impossible without default/empty constructor. However I would like for VideoInfo and other models of this library to be immutable.
For MVVM data bindings, best practice is to create your own models and not reuse models from api, because you do not control those models, and they can change.
Serialization is indeed an issue in a basic scenario (although, Json.Net, for example, can be told to deserialize using non-public members), but he was talking about DataBinding so I was wondering where manually instantiating is needed there.
The only two alternatives to having internal constructor to preserve immutability that I see are:
Actually I can just make a public constructor that sets all the properties in one go if you really need it. However I'd like to hear the use case first before I end up doing something.
It was for design-time binding using Caliburn.Micro. I appologize for the late response. I was requiring to instantiate VideoInfo
and I was unable to. Is there an objection to making the class public? What do you see as harmful as making it public?
No objections, just needs some work. I already started on a new branch.
Fixed by #21
DataBinding is difficult with VideoInfo (specifically in WPF) because most controls wont allow a null data source and we can't instantiate an instance of VideoInfo as it only has an internal constructor.