|
IMlemon posted:One of the core abstractions in the system i'm working on right now. I'm not seeing anything too awful here. You're creating a base class from which all messages shall derive, even if it does nothing by itself.
|
# ? Oct 18, 2013 13:53 |
|
|
# ? Jun 5, 2024 09:06 |
|
There are libraries that depend on empty base classes/interfaces to identify if the object is something the user intends the library to interact with.
|
# ? Oct 18, 2013 14:16 |
|
Volmarias posted:I'm not seeing anything too awful here. You're creating a base class from which all messages shall derive, even if it does nothing by itself. Generally you'd want the message to have at least one abstract/virtual function or piece of data or SOMETHING though right? Otherwise you don't really have any way to tie together why the messages need a base class in the first place? If it's to store them all in a specific typed queue or something then you still can't do anything with them because you can't call anything that they have in common. Edit: vvv Would it even make sense as an empty interface? You still need functions or data to interface with. Jewel fucked around with this message at 14:40 on Oct 18, 2013 |
# ? Oct 18, 2013 14:29 |
|
Bognar posted:There are libraries that depend on empty base classes/interfaces to identify if the object is something the user intends the library to interact with. It would make some sense if it were an empty interface, but an empty abstract class imposes itself on the inheritance chain for no benefit whatsoever.
|
# ? Oct 18, 2013 14:35 |
|
Jewel posted:Edit: vvv Would it even make sense as an empty interface? You still need functions or data to interface with. Not if you're using it solely as an identifier. There are also some other strange things you could do with it in C# with extension methods. If you, for some reason, had functionality that could be used on any object (e.g. a GetHashCode() wrapper) but you only wanted it to appear on certain objects, you could have those objects inherit from an empty interface and define an extension method for that interface. pigdog posted:It would make some sense if it were an empty interface, but an empty abstract class imposes itself on the inheritance chain for no benefit whatsoever. Yeah, an empty abstract class doesn't make too much sense because there's no reason not to use an empty interface at that point.
|
# ? Oct 18, 2013 15:10 |
|
Bognar posted:Not if you're using it solely as an identifier. There are also some other strange things you could do with it in C# with extension methods. If you, for some reason, had functionality that could be used on any object (e.g. a GetHashCode() wrapper) but you only wanted it to appear on certain objects, you could have those objects inherit from an empty interface and define an extension method for that interface. Doing this totally sucks and is a pet hate of mine. "Marker" interfaces indeed; terrible. If you want a GetHashCode or a ToString on some interface, put it on the interface?
|
# ? Oct 18, 2013 17:06 |
|
I'm not going to post the code as to not reveal industry secrets, but right now I'm looking at a caching fuckup. Basically, we deal with loans - each loan has its own object and metadata object attached. This guy was caching the metadata the first time you retrieve it from the server, and never updated the cache, which means that every time you went and got a list of loan objects, it was a snapshot of loans that existed at that point in time, not live data. Yeah, our business end users really freaked out.
|
# ? Oct 18, 2013 17:16 |
|
return0 posted:Doing this totally sucks and is a pet hate of mine. "Marker" interfaces indeed; terrible. If you want a GetHashCode or a ToString on some interface, put it on the interface? The point isn't to force the object to implement the functionality, but to provide the functionality and choose the object to use it on. It's like a gimped C# mixin.
|
# ? Oct 18, 2013 17:42 |
|
pigdog posted:It would make some sense if it were an empty interface, but an empty abstract class imposes itself on the inheritance chain for no benefit whatsoever. Why? In C++ this is a common pattern for type checking (your message handler accepts a BaseMessage* or whatever) and allows you to add additional functionality to the hierarchy without having to substantially refactor your code later... Is this a C#-specific peeve?
|
# ? Oct 18, 2013 17:51 |
|
shodanjr_gr posted:Why? In C++ this is a common pattern for type checking (your message handler accepts a BaseMessage* or whatever) and allows you to add additional functionality to the hierarchy without having to substantially refactor your code later... C#, like Java, does not support multiple inheritance from non-interface classes. So making an empty abstract base class severely limits your ability to modify things. C++ does support multiple inheritance, so it's not an issue. (Does C++ even have the concept of an interface, distinct from a pure virtual class?)
|
# ? Oct 18, 2013 17:58 |
|
Amarkov posted:C#, like Java, does not support multiple inheritance from non-interface classes. So making an empty abstract base class severely limits your ability to modify things.
|
# ? Oct 18, 2013 18:37 |
|
IMlemon posted:
Every once in a while I find myself using the word "encapsulates" in the description of a class. Then I stop and go outside for a few minutes.
|
# ? Oct 18, 2013 19:30 |
|
Enclassulate
|
# ? Oct 18, 2013 19:33 |
|
Those services and VMs that got obliterated back when I said the client for my company lost those services and VMs? Still down ALWAYS HAVE BACKUPS YA GOOFS
|
# ? Oct 18, 2013 20:06 |
|
Bognar posted:Not if you're using it solely as an identifier. There are also some other strange things you could do with it in C# with extension methods. If you, for some reason, had functionality that could be used on any object (e.g. a GetHashCode() wrapper) but you only wanted it to appear on certain objects, you could have those objects inherit from an empty interface and define an extension method for that interface. If you just want an identifier you'd probably want to use an attribute in C#. An added advantage is it implies no inheritance or implementation relationship at all. This wouldn't allow you to do weird backdoor mixins like you proposed but that seems like kind of a horror anyway.
|
# ? Oct 18, 2013 20:18 |
|
Monkeyseesaw posted:If you just want an identifier you'd probably want to use an attribute in C#. An added advantage is it implies no inheritance or implementation relationship at all. Yep, Microsoft has a static analysis rule that states exactly that. http://msdn.microsoft.com/en-us/library/ms182128%28v=VS.100%29.aspx quote:If your design includes empty interfaces that types are expected to implement, you are probably using an interface as a marker or a way to identify a group of types. If this identification will occur at run time, the correct way to accomplish this is to use a custom attribute. Use the presence or absence of the attribute, or the properties of the attribute, to identify the target types. If the identification must occur at compile time, then it is acceptable to use an empty interface. And yet, Microsoft doesn't follow their own advice (as usual). http://msdn.microsoft.com/en-us/library/system.web.sessionstate.irequiressessionstate.aspx http://msdn.microsoft.com/en-us/library/system.web.ui.inamingcontainer.aspx
|
# ? Oct 18, 2013 22:05 |
|
A marker interface with a type parameter could be useful in some circumstances. If a class extends the interface with a specific type, then that type can be retrieved at runtime through reflection. It can also be used to restrict the types of interfaces extending the interface. For instance:code:
|
# ? Oct 18, 2013 23:07 |
|
That sounds like something a C++ programmer would attempt when forced to use C#. You could probably accomplish the same thing, clearer, using type constraints.
|
# ? Oct 19, 2013 00:53 |
|
Bognar posted:Yep, Microsoft has a static analysis rule that states exactly that. If instead of an empty abstract class or interface, if you decorated all your classes with an attribute...how are you forcing whatever consistency or grouping you want? Reflection all over the place to check? I guess you could make an extension method to object that boolean returns if it has that attribute or not. ManoliIsFat fucked around with this message at 01:44 on Oct 19, 2013 |
# ? Oct 19, 2013 01:35 |
|
ManoliIsFat posted:If instead of an empty abstract class or interface, if you decorated all your classes with an attribute...how are you forcing whatever consistency or grouping you want? Reflection all over the place to check? I guess you could make an extension method to object that boolean returns if it has that attribute or not.
|
# ? Oct 19, 2013 01:59 |
|
Well, you can enforce at compile-time that a function only accepts parameters with the appropriate marker interface.
|
# ? Oct 19, 2013 08:45 |
|
Jabor posted:Well, you can enforce at compile-time that a function only accepts parameters with the appropriate marker interface. Yeah, the last sentence of the explanation of the FxCop rule even mentions this. There's pros and cons to either way of doing it and it's up to the developer to decide which is best for them. This FxCop rule should only be seen as a reminder that you might want to use an attribute, not as a "X is the wrong way, Y is the right way" type of rule.
|
# ? Oct 19, 2013 11:13 |
|
Keep in mind that checking for attributes is literally orders of magnitude slower than classes/interfaces. But that shouldn't matter unless you write game components or something.
|
# ? Oct 19, 2013 12:56 |
|
Monkeyseesaw posted:That sounds like something a C++ programmer would attempt when forced to use C#. You could probably accomplish the same thing, clearer, using type constraints. You could accomplish something similar using type constraints, but not that in particular. There's no inheritance relationship between Child1 and Child2, so implementing one doesn't require implementing the other. There's no limitations on the type parameters for either the parent or child interfaces. However iff you implement both child interfaces, then they must be the same type. This technique can be used in addition to type constraints to impose additional constraints on implementers of multiple interfaces. code:
|
# ? Oct 19, 2013 13:21 |
|
XKCD from a few days ago: The mouseover text is especially horrible. quote:If replacing all the '3's doesn't fix your code, remove the 4s, too, with 'ceiling(pi) / floor(pi) * pi * r^floor(pi)'. Mmm, floor pie.
|
# ? Oct 21, 2013 19:06 |
|
It's... a joke? Why would you post it here?
|
# ? Oct 21, 2013 21:44 |
|
KaneTW posted:It's... a joke? Why would you post it here? Coding horrors: post the code that makes you laugh (or cry) It seemed funny, and it is code. Its made up, but so are some of the things we post here. If you found that in the wild, it'd be a horror.
|
# ? Oct 21, 2013 22:04 |
|
Well xkcd is certainly a horror.
|
# ? Oct 22, 2013 00:04 |
|
Zaphod42 posted:Coding horrors: post the code that makes you laugh (or cry) Fair enough, I just thought you were one of the people who go "XKCD is bad "
|
# ? Oct 22, 2013 00:11 |
|
It is though, and that "joke" proves it
|
# ? Oct 22, 2013 00:30 |
|
XKCD is ok and his what if blog is pretty interesting. He hasn't done a comic about ~*Megan*~ in years so the strip is basically free of goony desperation.
|
# ? Oct 22, 2013 05:01 |
|
They got married and then she got cancer.
|
# ? Oct 22, 2013 05:49 |
|
code:
|
# ? Oct 22, 2013 12:53 |
|
an insufferable third party posted:How am I supposed to know if my API works if you haven't given me a working consumer of it? Today is going to be fun.
|
# ? Oct 22, 2013 13:43 |
|
leper khan posted:Today is going to be fun. "How do I know my consumer will work if you don't give me an API?"
|
# ? Oct 22, 2013 13:56 |
|
leper khan posted:Today is going to be fun. The correct answer is "your unit tests".
|
# ? Oct 22, 2013 14:07 |
|
Ithaqua posted:The correct answer is "your unit tests". I'm just gonna take a stab in the dark and assume that they don't have any.
|
# ? Oct 22, 2013 14:18 |
|
If a third-party is asking about your API, I think it's more than acceptable to ask for an example of a consumer for documentation and evaluation purposes.
|
# ? Oct 22, 2013 14:24 |
|
So, running over some old code dealing with our calendar API and found CamelDiscoDiary. That's a drat good class name.
|
# ? Oct 22, 2013 15:38 |
|
|
# ? Jun 5, 2024 09:06 |
|
Suspicious Dish posted:If a third-party is asking about your API, I think it's more than acceptable to ask for an example of a consumer for documentation and evaluation purposes. A third party is /providing/ an API, and doesn't know if it works because I haven't provided them a working client application.
|
# ? Oct 22, 2013 16:39 |