Skip to main content
14 events
when toggle format what by license comment
Dec 24, 2014 at 17:31 comment added supercat @UriAgassi: Code which checks for the existence of attributes can check to see exactly where they occur, and thus make them behave as if they are inherited or not as it sees fit. In general, however, if a base type sets an attribute one way and a derived type sets it another, code which looks for the attribute will only find out about the base-type one if it explicitly looks for it. By contrast, if a type implements an interface, there's no mechanism by which a derived type can "unimplement" it.
Dec 23, 2014 at 21:19 comment added Uri Agassi @supercat AFAIK attributes can be inherited
Dec 23, 2014 at 17:38 comment added supercat A key difference between interfaces and attributes is that interfaces make promises on behalf of an implementing class and any class derived from it, while attributes are applicable only to the class applying them, and not to descendants thereof. If characteristics should be inherited, use interfaces; if not, use attributes.
Mar 3, 2014 at 14:16 comment added Rondles @BenAaronson I agree. Which is why I was initially considering removing the IParsedRow interface as a solution to the code smell. As I'm now using it, the point has been invalidated but this has still been a though provoking conversation for me.
Mar 3, 2014 at 14:10 comment added Ben Aaronson @Rondles While compile time errors are preferable to run time, I'm not sure that really falls under the realm of code smells. Having said that, this isn't exactly the normal use for an attribute. Perhaps you should think about whether any specific marking in code of a Parsed Row is really needed at all. In my experience, classes like these (e.g. Model classes in ASP.NET MVC) don't have any special marking. Conceptually all you're really saying is that it has publically accessible properties
Mar 3, 2014 at 14:04 comment added Rondles Well the use of type constraints is a language feature, built to help restrict the use of Type Parameters at compile time. Having to code in a check that a specific Attribute is being used will result in a runtime error if it doesn't. (Unless of course I'm missing some sort of compile time trick you can pull?)
Mar 3, 2014 at 14:02 comment added Ben Aaronson @Rondles Why do you consider that a code smell?
Mar 3, 2014 at 13:58 comment added Rondles @BenAaronson I did feel like a bit of a fraud doing it, BUT I will genuinely use it (in fact I drew it into my domain design but overlooked it when building the classes and interfaces). Which raises another question, if you cant specify that a type must be decorated by an attribute but instead check for it elsewhere (like the constructor) is this itself not adding a different code smell?
Mar 3, 2014 at 13:56 comment added Ben Aaronson @Rondles That sounds sensible, though in general you should make sure your mentality is "I need this property so an interface is the right tool for the job" rather than "I want an interface, so what would be a nice property to put on it?"
Mar 3, 2014 at 13:53 vote accept Rondles
Mar 3, 2014 at 13:53 comment added Rondles Right I see. Well after all of this I have realised that my interface could actually do with at least one property which is row number which I've realised i'll need for anything which is a Row. So I guess that eliminates the code smell. Although attributes have intrigued me now as I think other parts of my code can benefit.
Mar 3, 2014 at 13:51 comment added Ben Aaronson @Rondles No, you can't. If you wanted to ensure that, you'd have to do a check somewhere- probably the constructor.
Mar 3, 2014 at 13:48 comment added Rondles Thanks. So can you specify that a particular Type Parameter must be decorated with a specific attribute (e.g. where TEntity : ParsedRowAttribute)
Mar 3, 2014 at 13:44 history answered Uri Agassi CC BY-SA 3.0