 |
|
|
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?
|
|
|
|
|
|
|
Nice one... looking forward to a possible explanation 
(yes|no|maybe)*
|
|
|
|
|
|
|
He must be sleeping  while coding 
Explanation:
Currently we allow only internal implementation, in future we may allow external as well, so we have interface.
Does it make any sense??
|
|
|
|
|
|
|
Ankush Bansal wrote: Does it make any sense??
Er... no... but what does
(yes|no|maybe)*
|
|
|
|
|
|
|
|
|
|
Perhaps it is some kind of Monomorphism implementation using interfaces 
|
|
|
|
|
|
|
|
|
|
That is bizarre. I wonder what was going through the original coder’s head?
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
|
|
|
|
|
|
|
Skydiving with a malfunctioning parachute?
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
Yeah, that sounds logical. The original coder really should have added comments to explain what he was doing and why. Unfortunately, those kind of comments are all too rare. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
|
|
Has anyone ever come across and entire project where every class, every function is a static, for no good reason at all. Just a ton of statics and delegates and that is it. It is a pretty large project.
|
|
|
|
|
|
|
Sounds ideal to me; why use OOP when you don't need it?
|
|
|
|
|
|
|
|
|
|
|
|
|
Written by a former VB6 programmer?
|
|
|
|
|
|
|
Why, yes, I have seen a project with everything that could be made static was made static, but they did have a reason. When I asked why all those methods were static, I was told "so that they can be called by an outside program". I didn't say they had a good reason.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
|
|
Not everything, but really a lot: WPF.
|
|
|
|
|
|
|
One place I interviewed at a few years ago showed me their code -- every class was a Singleton!  -- I didn't ask for the job.
|
|
|
|
|
|
|
Once upon a time
Manager: Show me your design diagrams.
Developer: Here they are but I am still working on it.
Manager: Where is the class for our front page.
Developer: (confused) That would be a static page so we dont need the classes.
Manager: OK now you work on task 2. i will get this one done by developer 2.
Later that day
Developer2: Is it complete
Manager: yes.
Developer2: where are the relationships between classes?
Manager: hmm, well all these classes and functions are static so we don't need them.
Developer2:WHAT?
Manager: yes now go and do it before I sack you.
|
|
|
|
|
|
|
|
|
|
Maybe he just wants tables, not the random crap (not working in some browsers) you can get from using an ASP control.
|
|
|
|
|
|
|
I'm reading a 790 line SQL sproc, a lot of poor coding peppered with extrainious begin/end statements. It starts early on with a "begin tran" lots of poor inserts and updates. Looks like SQL 2000 code, no try/catch logic, then the kicker:
End
IF @@ERROR <> 0
-- error statements using the first needed begin/end block
Else
Commit Tran
End
That was the first reference in the whole novel to @@ERROR! (Code created for Msft)
For those who don't know SQL, that "End" before the "IF" FORCES it to always try to Commit the transaction, no matter how many errors the user has hit by now.
|
|
|
|
|
|
|
I have seen something like that. A big problem if it's in a high security thing.
return true;
|
|
|
|
|
RSS feed
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin