come on give me a break !!
-
Just saw this: public interface IInterface { //some interface } internal SomeClass : IInterface { } public class PublicAPI { public void PublicFunc(IInterface i) { if(!(i is SomeClass)) { throw new Exception("External implementation of IInterface is not allowed!!"); //what a crap?? } } } why on earth would you expose an interface if you restrict it to one single concrete implementation?:mad:
-
Just saw this: public interface IInterface { //some interface } internal SomeClass : IInterface { } public class PublicAPI { public void PublicFunc(IInterface i) { if(!(i is SomeClass)) { throw new Exception("External implementation of IInterface is not allowed!!"); //what a crap?? } } } why on earth would you expose an interface if you restrict it to one single concrete implementation?:mad:
-
Just saw this: public interface IInterface { //some interface } internal SomeClass : IInterface { } public class PublicAPI { public void PublicFunc(IInterface i) { if(!(i is SomeClass)) { throw new Exception("External implementation of IInterface is not allowed!!"); //what a crap?? } } } why on earth would you expose an interface if you restrict it to one single concrete implementation?:mad:
-
He must be sleeping :zzz: while coding :laugh: Explanation: Currently we allow only internal implementation, in future we may allow external as well, so we have interface. Does it make any sense??:confused:
-
He must be sleeping :zzz: while coding :laugh: Explanation: Currently we allow only internal implementation, in future we may allow external as well, so we have interface. Does it make any sense??:confused:
-
Just saw this: public interface IInterface { //some interface } internal SomeClass : IInterface { } public class PublicAPI { public void PublicFunc(IInterface i) { if(!(i is SomeClass)) { throw new Exception("External implementation of IInterface is not allowed!!"); //what a crap?? } } } why on earth would you expose an interface if you restrict it to one single concrete implementation?:mad:
Perhaps it is some kind of Monomorphism implementation using interfaces :-)
-
Just saw this: public interface IInterface { //some interface } internal SomeClass : IInterface { } public class PublicAPI { public void PublicFunc(IInterface i) { if(!(i is SomeClass)) { throw new Exception("External implementation of IInterface is not allowed!!"); //what a crap?? } } } why on earth would you expose an interface if you restrict it to one single concrete implementation?:mad:
-
That is bizarre. I wonder what was going through the original coder’s head? :confused:
Just because the code works, it doesn't mean that it is good code.
His ass?
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
His ass?
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Perhaps it is some kind of Monomorphism implementation using interfaces :-)
-
Just saw this: public interface IInterface { //some interface } internal SomeClass : IInterface { } public class PublicAPI { public void PublicFunc(IInterface i) { if(!(i is SomeClass)) { throw new Exception("External implementation of IInterface is not allowed!!"); //what a crap?? } } } why on earth would you expose an interface if you restrict it to one single concrete implementation?:mad:
One reason I can think of is to reduce the impact of a later change. So, you have IAnimal, implemented by both Duck and Dog. It would be useful to keep collections of IAnimal so you can hold both your Ducks and Dogs and perform IAnimal operations on them. However, suppose you can't get to implementing Dog yet, but you know it will exist in the future. You might code toward a known future objective that doesn't appear to be of any use yet. "Why not make IAnimal an internal class so it isn't visible outside the assembly", you ask. Well, that interface and the classes that implement it may be required in multiple assemblies.
-
One reason I can think of is to reduce the impact of a later change. So, you have IAnimal, implemented by both Duck and Dog. It would be useful to keep collections of IAnimal so you can hold both your Ducks and Dogs and perform IAnimal operations on them. However, suppose you can't get to implementing Dog yet, but you know it will exist in the future. You might code toward a known future objective that doesn't appear to be of any use yet. "Why not make IAnimal an internal class so it isn't visible outside the assembly", you ask. Well, that interface and the classes that implement it may be required in multiple assemblies.
-
One reason I can think of is to reduce the impact of a later change. So, you have IAnimal, implemented by both Duck and Dog. It would be useful to keep collections of IAnimal so you can hold both your Ducks and Dogs and perform IAnimal operations on them. However, suppose you can't get to implementing Dog yet, but you know it will exist in the future. You might code toward a known future objective that doesn't appear to be of any use yet. "Why not make IAnimal an internal class so it isn't visible outside the assembly", you ask. Well, that interface and the classes that implement it may be required in multiple assemblies.
I think you are missing a point here:rose:. The issue is not that they have exposed an interface say IAnimal and they only have Duck implementation, and Dog's is pending. The issue is they throwing an exception if concrete impl of IAnimal is external (even if its else's Duck). Point being why to create a false API? Why to show that API can handle any IAnimal but would throw if animals are external. :laugh: Why can't an IAnimal be external? why can't someone else's Duck be processed? I personally believe that if any point there is a need of such check then either one should make concrete impl of Duck public and take that as input in func or one can have a public proxy for Duck.
-
I think you are missing a point here:rose:. The issue is not that they have exposed an interface say IAnimal and they only have Duck implementation, and Dog's is pending. The issue is they throwing an exception if concrete impl of IAnimal is external (even if its else's Duck). Point being why to create a false API? Why to show that API can handle any IAnimal but would throw if animals are external. :laugh: Why can't an IAnimal be external? why can't someone else's Duck be processed? I personally believe that if any point there is a need of such check then either one should make concrete impl of Duck public and take that as input in func or one can have a public proxy for Duck.
Being a bit of a devils' advocate here. I think this code definitely require a better message in the exception or description in the code. However Perhaps the programmer want to prevent the class from being inherited. This is why he made it internal. He could have make it public and sealed and as I see it get the same effect. Sometime when you define an api though, it might not be such a bad idea to keep everything in interfaces. This way the library can be modified without impacting the Interfaces that have been exposed previously.
