Properties in interfaces are great, especially if you build APIs and like to have Sub-APIs related to the parent one. Gives a nice structure, makes also room for DI etc. I like them and my customers love the fluent usage of my APIs - for example. 😊
Another good use of properties in interfaces is to obtain a Trait-like behavior in C#. I like to break clusters of properties (and related functions) into simple interfaces that a lot of large objects can implement.
Not using properties on interfaces would be a minority view to say the least and properties are methods under the hood anyway. I'm very selective about what I make public but if I do make something public, it's a candidate for an interface.
Hi Sean, totally agree. Did not find right place to ask this question so asking here, do you have video about wpf app localization? What approach do you recommend ? Thank you in advance!
Good question! In the past, I've worked on apps that use resource files (.resx). You can have a resx file per locale, with each resx file having keys that point to localized content. I can cover this in a video!
This is kinda C# issue in general. Interface often describes behaviour and used as an abstraction and contract. So if interface describes type through its behaviour and it is weird to have accessor to field(I know its property) as contract. Property has methods get and set so it is making things obscure what is exact definition of your type (how can you describe type by method GetName and/or SetName? Namer? Nameror?). It is more of an academical viewpoint on interfaces/traits/type classes.
I often use interfaces when two objects have similar properties that I wanna set the same way. For me having properties inside an interface is one of the main use cases.
Default interface implementations do feel weird. I haven't even thought to use it yet 😄 it just goes against the idea of interfaces imo but I'm sure there's some place where it might make sense
"Including properties in an interface forces any class implementing that interface to provide those properties, even if they are not relevant to the class's purpose or behavior". Including methods in an interface forces any class implementing that interface to provide those methods, even if they are not relevant to the class's purpose or behavior. "If your interface contains properties, you are doing something wrong. You are forcing these properties on anything that implements this contract". If your interface contains methods, you are doing something wrong. You are forcing these methods on anything that implements this contract. If you are forcing users of your interface to implement ANYTHING that they don't want to implement, then you have a bad interface. This has absolutely nothing to do with methods vs properties. These same people will stick a property on an abstract class and be smug about it even though they have literally done the exact same thing except now you have actual tangible data that a child class might not want.
Ummm. Ok so are we talking only about abstraction or we are talking about OOP principles altogether. I am totally agree with you if I go with FP or semi FP languages. Abstraction = behaviour, period. But if you are building abstraction on top of the existing concrete types in oop? Leaky? Well yes, but this is sometimes unavoidable. So academics or ultragranular interface segregation is cool and all but why ms added ability to add properties to interfaces? Or TypeScript having ability to have prop interface? Why? What it solves? Maybe it because of high level vs low level of abstraction layers? Dunno actually. I am in both camps right now. In C# I will describe interface through properties sometimes like in IConfigSection or something like that. Coz it is already high level enough. But if I will work with serde library probably will have ISerializable.
Either you have data or you're abstracting behavior. Do you really want to abstract the getters of properties? In that case rethink whether this is a property. You wouldn't put public fields in an interface...
