|
First an instruction: please use <pre></pre> tags around your code to make it readable; use the "code block" button in the editor.
Second an answer: although the x fields are private they are accessible to any method of the class, and since other is an object of the same class then the DistanceTo() method can access it.
|
|
|
|
|
Because DistanceTo is a member of the Point class.
|
|
|
|
|
A class is not equal to an object, but rather a template from which you can create multiple objects.
In this case you use object A's method to compare it with object B, both A and B are instances from the same class.
so if you use the compare method of Object A and pass it a parameter object B, both have the same properties.
maybe it makes more sense if you create (just for tests) a class C that has something like this:
public bool CompareObjects(ClassInstance A, ClassInstance B){
bool success = false;
if(A.x == B.x and A.y == B.y){
success = true;
}
return true;
}
in this sample you see that A and B are both objects instanciated by the ClassInstance class.
Hope this helps.
V.
|
|
|
|
|
The accessibility keywords (such as private) apply to the entire class, not to the individual instances; therefore if this Point can access the other Point, it can certainly access all its members.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
I just wanted to say thanks to all those that have taken the time to answer this. You have all helped and I understand what is going on now. Although I didn't describe exactly what was confusing me some of you spotted it - how can I use something private in another object but after reading the answers I understand better that private variables are available to any object that is a member of the class. Thanks very much for putting me right.
Cheers
Dave
|
|
|
|
|
In programming point of view Which is more usefull Abstract Class or Interface and Why?
|
|
|
|
|
They're both useful. They do something different.
Abstract classes can define fields and implement methods, but a class can only derive from one of them and a struct can not derive from them.
Interfaces can only define method signatures (including properties, indexers etc), but classes and structs can implement as many of them as they want.
|
|
|
|
|
An abstract class is generally useful when you are providing a partially or almost functional class, but you require certain things to be overridden to make it fully functional. For example, although they didn't, it would have made sense for Microsoft to make UserControl abstract and make its OnPaint method abstract. Or in my game lobby[^], the BaseLobby is abstract to provide some reusable code to both client and server.
An interface is generally useful when you want otherwise not directly related classes (i.e. they are not part of the same inheritance tree within your code, e.g. two custom controls, or a 'view' in MVC parlance that displays to the screen and one which sends information down a network) to expose common functionality. An interface can be used to 'patch in' functionality into objects that already have an inheritance tree. For example the interface INotifyPropertyChanged – any type of object can be declared to be the source of notification events, without any reason to restrict it to one part of the inheritance branch.
The functionality you're trying to patch in is usually small, most interfaces will only be a few methods, though there are some dubious cases in the framework. (Why would you want to implement IList<T> from scratch, for example?) The downside of an interface is that you need to implement all the methods (and properties) yourself in each class that implements it, which is why they should be simple.
So the short answer is: both, depending on what you want to do.
|
|
|
|
|
Abstract Class or Interface are different for working.
You can use only one abstract class with any class. But u can use multiple interface.
You can use concrete method or properties with abstract class. but this facility is not available with interface.
If you can think then I Can.
|
|
|
|
|
This really smells like a homework question to me.
A way to think about it. An interface is a contract. It states that your class will have certain elements, but it puts no constraints on how they will be achieved. An abstract class defines some common functionality that you can override and extend as appropriate.
With an interface, you can cast an object to the interface (providing it implements it), and call the functionality on it. This is how IDisposable works with the using statement. Effectively, the following code
(using Myclass c = new Myclass())
{
}translates to
Myclass c = null;
try
{
}
finally
{
((IDisposable)c).Dispose();
}Now, you said "In programming", so there's an additional consideration to take into account. In C#, you cannot have multiple inheritance (where you can in C++). What you can do in C# though, is support multiple interface implementation, so your class can inherit from one class but you can implement many interfaces. You note that I said, in C#, there. There's a common misconception that you can't do multiple inheritance in .NET. That's not true. The constraint is put in place by the language, and not the runtime, so if a .NET language chose to allow multiple inheritance, that would be supported. Until I can find the citation for this, please disregard this statement (it's from a very old interview, so it's taking me some time to find it).
I'm not a stalker, I just know things. Oh by the way, you're out of milk. Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Onyx
modified on Thursday, April 14, 2011 8:22 AM
|
|
|
|
|
Pete O'Hanlon wrote: There's a common misconception that you can't do multiple inheritance in .NET. That's not true. The constraint is put in place by the language, and not the runtime, so if a .NET language chose to allow multiple inheritance, that would be supported.
Not sure where you get that, but ECMA 335 (the CLI spec, not the C# spec) has this to say about it on page 161/556:
The extends keyword specifies the base type of a type. A type shall extend from exactly one other type. If no type is specified, ilasm will add an extends clause to make the type inherit from System.Object.
|
|
|
|
|
David1987 wrote: Not sure where you get that, but ECMA 335 (the CLI spec, not the C# spec) has
this to say about it on page 161/556:
It's from an interview that Anders made around about 2002. I'll have a hunt round and see if I can find it.
|
|
|
|
|
Until I can find the citation, I've struck through the section.
|
|
|
|
|
Ok, well, please find it 
This is rather odd so I'd prefer to get to the bottom of it
|
|
|
|
|
It could be that Anders said that while the underlying framework would support it, they made it so that the CLI inhibited it. I'm operating off an old memory here (I probably read this about 8 years ago).
|
|
|
|
|
I tried this in CIL :
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89)
.ver 4:0:0:0
}
.assembly CILTypes
{
.ver 1:0:0:0
}
.module CILTypes.dll
.namespace MyCompany
{
.namespace MyNameSpace
{
.class public interface IMyInterface {}
.class public MyBaseClass
{
}
.class public MyAnotherBaseClass
{
}
.class public MyDerivedClass
extends MyCompany.MyNameSpace.MyBaseClass
extends MyCompany.MyNameSpace.MyNotherBaseClass
implements MyCompany.MyNameSpace.IMyInterface
{
}
}
}
and the compiler throws this error
MyBaseClass.il(30) : error : syntax error at token 'extends' in : extends myCompany.MyNameSpace.MyBaseClass. So I guess it would be a restriction on all .Net languages.
...and I have extensive experience writing computer code, including OIC, BTW, BRB, IMHO, LMAO, ROFL, TTYL.....
|
|
|
|
|
As I just said, it could be that Anders said that they imposed this restriction in the CLI. He definitely said that they could extend it to do it if they had to, but he saw no compelling reason to do so, and about a thousand arguments against. Once I find the interview, I'll post the link.
|
|
|
|
|
|
Sounds like a homework question. It's a subjective call based on the context of the code. Both have their uses and both are better than the other within a specific context.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
If I could have only one, I'd pick interface. I won't tell you why.
|
|
|
|
|
PIEBALDconsult wrote: I won't tell you why
Let me guess, you're a concrete guy.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Me too, but I won't say why either!
|
|
|
|
|
You can answer that yourself; just take an existing app that uses both, then try and rewrite it once without using abstract classes, and once without using interfaces. I trust you will never forget the conclusions.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Tell your lecturer from me that is an imbicile question. It is like saying which is fruitiest, apples or oranges. Both are useful, both have a specific job to do.
|
|
|
|
|
Plums.
There are just some times when you have to say plums.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
