Timeline for Should an object's capabilities be identified exclusively by the interfaces it implements?
Current License: CC BY-SA 3.0
37 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 12, 2018 at 16:00 | vote | accept | TheCatWhisperer | ||
| Dec 19, 2017 at 20:35 | answer | added | Vadim Samokhin | timeline score: 0 | |
| Dec 16, 2017 at 5:48 | history | tweeted | twitter.com/StackSoftEng/status/941907821423194112 | ||
| Dec 13, 2017 at 15:22 | history | protected | gnat | ||
| Dec 13, 2017 at 15:15 | answer | added | Danikov | timeline score: 1 | |
| Dec 13, 2017 at 2:53 | comment | added | spender |
@IllidanS4 The WinRT stream interfaces have IInputStream, IOutputStream, IRandomAccessStream. Far more sensible that the (usually partially redundant) abstract Stream.
|
|
| Dec 13, 2017 at 2:48 | comment | added | spender | Branching on type. Usually bad. There are many design patterns that exist to factor this smell out of your code. | |
| Dec 12, 2017 at 22:00 | comment | added | Newtopian | The mere fact that an explicit cast is required tells me something is not quite right with the object structure... Both propositions look just as bad from here. | |
| Dec 12, 2017 at 15:53 | answer | added | AnoE | timeline score: 0 | |
| Dec 12, 2017 at 14:00 | history | edited | TheCatWhisperer |
edited tags
|
|
| Dec 12, 2017 at 2:10 | comment | added | IS4 | Another important point - the result of CanResetPassword might change over time or depend on other factors. Take it into consideration when deciding which one is better. You cannot change which interface you implement, so if suddenly you couldn't reset the password via IResetsPassword, you would have to throw an exception, effectively breaking the purpose you used interfaces for in the first place. | |
| Dec 12, 2017 at 2:07 | comment | added | IS4 | Once example I can think of is the Stream. It has CanRead and CanWrite to go with Read and Write. While I sometimes would like to be able to explicitly limit the parameter type by some OutputStream or InputStream, you would have to have multiple inheritance for other classes, like FileStream, for example (with some InputFileStream derived from both InputStream and Stream). | |
| Dec 11, 2017 at 21:41 | answer | added | candied_orange | timeline score: 89 | |
| Dec 11, 2017 at 20:37 | answer | added | JimmyJames | timeline score: 1 | |
| Dec 11, 2017 at 20:31 | comment | added | user22815 | I disagree that this is too broad: looking at the general case, there is a reasonably-scoped approach. | |
| Dec 11, 2017 at 20:16 | review | Close votes | |||
| Dec 15, 2017 at 15:31 | |||||
| Dec 11, 2017 at 20:13 | answer | added | user22815 | timeline score: 17 | |
| Dec 11, 2017 at 19:30 | comment | added | user251748 | AI is starting to seem easier and easier. | |
| Dec 11, 2017 at 18:32 | answer | added | Alex | timeline score: 8 | |
| Dec 11, 2017 at 18:10 | history | edited | TheCatWhisperer | CC BY-SA 3.0 |
added 100 characters in body
|
| Dec 11, 2017 at 18:05 | answer | added | Emerson Cardoso | timeline score: 0 | |
| Dec 11, 2017 at 17:53 | comment | added | Euphoric | This question might seem simple, but grows quite broad when you start thinking about it. Questions that pop into my mind: Are you expecting to add new behaviors to existing accounts or create account types with different behaviors? Do all account types have similar behaviors or are there big differences between them? Does the example code know about all the types of the accounts or just basic IAccount interface? | |
| Dec 11, 2017 at 17:49 | comment | added | MetaFight | Your question title and question body ask different things. To answer the title: Ideally, yes. To address the body: If you find yourself checking type and manually casting, you're probably not leveraging your type system correctly. Can you tell us more specifically how you found yourself in this situation? | |
| Dec 11, 2017 at 17:45 | comment | added | Robert Harvey | @nocomprende: xkcd.com/927 | |
| Dec 11, 2017 at 17:44 | comment | added | user251748 | It is so good that there are so many rules and guidelines to choose from! | |
| Dec 11, 2017 at 17:44 | comment | added | Becuzz |
@TheCatWhisperer I'm not sure how that makes a difference. You ultimately have to cast your object to IResetPassword or IResetPasswordThatTakesABunchOfArguments. The type system will tell you that (if you do a check and when you actually do the cast). I fail to see what CanResetPassword tells you that the type checks don't.
|
|
| Dec 11, 2017 at 17:44 | comment | added | Robert Harvey | @nocomprende: The one that most effectively meets your specific requirements. | |
| Dec 11, 2017 at 17:39 | comment | added | TheCatWhisperer | @Becuzz their might be several different ways to reset a password, with different arguments | |
| Dec 11, 2017 at 17:38 | comment | added | Becuzz |
@TheCatWhisperer If you do a type check, then what is the point of CanResetPassword? At that point you are back to the first example.
|
|
| Dec 11, 2017 at 17:37 | comment | added | TheCatWhisperer | @Becuzz ideally, in the second one, you'd do a type check too... editing now | |
| Dec 11, 2017 at 17:36 | comment | added | Becuzz |
Just my opinion, but I'd go with the first one just because it makes sure you can safely cast to the appropriate type. The second one assumes that CanResetPassword will only be true when something implements IResetsPassword. Now you are making a property determine something the type system should control (and ultimately will when you preform the cast).
|
|
| Dec 11, 2017 at 17:36 | comment | added | Emerson Cardoso | I guess if your capabilities are set statically (won't change once the app starts running), then using the interface to represent the presence of it would work (although I don't like any of your two examples). But, if in your app, the same account can acquire some capability over time, then this approach of yours won't be suitable enough; then maybe flags would be better; and command pattern for the execution of the operations. | |
| Dec 11, 2017 at 17:35 | comment | added | TheCatWhisperer | also the first example is more "DRY", the second is more flexible if you need it | |
| Dec 11, 2017 at 17:34 | comment | added | user251748 | So which of those two rules is better? | |
| Dec 11, 2017 at 17:32 | comment | added | Robert Harvey | Of course, as with all things programming, it depends. You could look at this as "favor composition over inheritance," in which case the second example is better. Or you could look at this as fulfilling a specific contract, in which case the first example is better. | |
| Dec 11, 2017 at 17:30 | comment | added | Robert Harvey | Look at your two code examples. Which one is more readable? | |
| Dec 11, 2017 at 17:28 | history | asked | TheCatWhisperer | CC BY-SA 3.0 |