M
Marius Horak
As in subject.
Thanks
MH
Thanks
MH
N
n!
As in subject.
Typically you use the message body to provide a more complete description of
your question ;o)
Any good reason for not using an interface for what? I wouldn't use them for
everything. But I do use them frequently.
n!
Typically you use the message body to provide a more complete description of
your question ;o)
Any good reason for not using an interface for what? I wouldn't use them for
everything. But I do use them frequently.
n!
M
Marius Horak
Sorry n!, you answer do not provide anything costructive.
I only hope you were trying to help and not to use keyboard and fingers
without using brain.
But do you realy think you help me?
MH
I only hope you were trying to help and not to use keyboard and fingers
without using brain.
But do you realy think you help me?
MH
A
Andreas Håkansson
Marius
I would say that the previous reply to your post was more constructive
then your question. Please post a proper question, stating what you are
wondering and why. If you do not want to provide more information then
what you already have done, then you will have to do with the short answer
"Yes there are good reasons for not using interfaces in SOME situations".
//Andreas
I would say that the previous reply to your post was more constructive
then your question. Please post a proper question, stating what you are
wondering and why. If you do not want to provide more information then
what you already have done, then you will have to do with the short answer
"Yes there are good reasons for not using interfaces in SOME situations".
//Andreas
M
Marius Horak
Andreas Håkansson said:
Do you mean that is I ask how to get from A to B I have to say 'what and
why' as well?
If someone does not like my question the best way is to ignore it. Or if you
feel so strongly just sue me.
So far so many characters have been used and still no good reason for not
using interface.
Please bare in mind that this is a technical NG and not general purpose.
situations".
Could you elaborate on 'in SOME situations' please?
MH
A
Andreas Håkansson
Marius,
Many of us spend our time helping people on this list, so there is no
need to be rude when someone asks you to clairify your question so a
correct answer can be given.
When to use and not to use interfaces all depends on the context of the
situation. If you for example talk about Remoting then there are pros and
cons of using interfaces. If you talk in normal OOP design, then an
interface
is usefull when a class "supports" some shared functionality so the classes
can be used in a polymorphic fashion. But then again an interface is not a
subsitute for an abstract base class. Interfaces is also the only way you
can
provide a close thing to multiple inheritence in C#.
When to use an interface depends on the context - so your easy question
is without an equality easy answer, therefor I asked you to elaborate on in
what situation you mean.
//Andreas
Many of us spend our time helping people on this list, so there is no
need to be rude when someone asks you to clairify your question so a
correct answer can be given.
When to use and not to use interfaces all depends on the context of the
situation. If you for example talk about Remoting then there are pros and
cons of using interfaces. If you talk in normal OOP design, then an
interface
is usefull when a class "supports" some shared functionality so the classes
can be used in a polymorphic fashion. But then again an interface is not a
subsitute for an abstract base class. Interfaces is also the only way you
can
provide a close thing to multiple inheritence in C#.
When to use an interface depends on the context - so your easy question
is without an equality easy answer, therefor I asked you to elaborate on in
what situation you mean.
//Andreas
M
Marius Horak
Andreas,
n! did not ask me to clarify my question. He/she just did not like it.
I can bet that he/she does not do it everytime so his/her action (reaction)
is selective.
Why I asked the question?
Well, I have to maintain an old system where most of objects are based on
interface.
In one case I have to add a new parameter to one of the methods.
This interface is used as base for 42 objects but the change is relevant to
one object only.
Without interface all would be simple as the method is referenced by the
object 7 times. With interface I face changing 411 lines adding useless
parameter or to create a separate object that will be 99% like other 41
objects.
Having this experience I will never use interface in my code.
MH
Andreas Håkansson said:
n! did not ask me to clarify my question. He/she just did not like it.
I can bet that he/she does not do it everytime so his/her action (reaction)
is selective.
Why I asked the question?
Well, I have to maintain an old system where most of objects are based on
interface.
In one case I have to add a new parameter to one of the methods.
This interface is used as base for 42 objects but the change is relevant to
one object only.
Without interface all would be simple as the method is referenced by the
object 7 times. With interface I face changing 411 lines adding useless
parameter or to create a separate object that will be 99% like other 41
objects.
Having this experience I will never use interface in my code.
MH
A
Andreas Håkansson
Marius,
Once an interface has been published it may never be changed or
you will be breaking it. If you need to add a new parameter to an existing
interface method then you should create a second interface which contains
the new method overload and implement it. Then you have the old method
throw an NotImplementedException.
interface IFoo
{
void Foo(int a);
}
interface IFoo2
{
void Foo(int a, int b);
}
public class Bar : IFoo, IBar
{
public Bar()
{
}
// Implement IFoo.Foo(int a)
public void Foo(int a)
{
throw new NotImplementedException();
}
// Implement IFoo2.Foo(int a, int b)
public void Foo(int a, int b)
{
// Work your magic
}
}
If you look at Win32 you will see this all over the place. Infact if you
read any
books/resources on OOP you will see this.
HTH,
//Andreas
Once an interface has been published it may never be changed or
you will be breaking it. If you need to add a new parameter to an existing
interface method then you should create a second interface which contains
the new method overload and implement it. Then you have the old method
throw an NotImplementedException.
interface IFoo
{
void Foo(int a);
}
interface IFoo2
{
void Foo(int a, int b);
}
public class Bar : IFoo, IBar
{
public Bar()
{
}
// Implement IFoo.Foo(int a)
public void Foo(int a)
{
throw new NotImplementedException();
}
// Implement IFoo2.Foo(int a, int b)
public void Foo(int a, int b)
{
// Work your magic
}
}
If you look at Win32 you will see this all over the place. Infact if you
read any
books/resources on OOP you will see this.
HTH,
//Andreas
M
Marius Horak
Andreas Håkansson said:
And all of this fuss can be avoided by not using interface.
MH
A
Andreas Håkansson
Marius,
I am not going to preach oop to you. But if you believe that millions
of developers are totaly wrong then you are entitled to have that oppinion,
if not I recommend you pick up an oop book at your local bookstore =)
Removing the interface removes all your abilities of using polymorphism.
//Andreas
I am not going to preach oop to you. But if you believe that millions
of developers are totaly wrong then you are entitled to have that oppinion,
if not I recommend you pick up an oop book at your local bookstore =)
Removing the interface removes all your abilities of using polymorphism.
//Andreas
N
n!
n! did not ask me to clarify my question. He/she just did not like it.
I'm a 'he' btw (last time I looked, anyway).
Anyway, I did ask:
Which was basically me asking for clarification. My first sentence was a
(lame) attempt at making the mail a bit more 'friendly' (hence the smiley)
)
I replied in the way I did because there was no-way to answer your original
question without simply guessing what you actually wanted.
Your clarification asks your question much better
n!
I'm a 'he' btw (last time I looked, anyway).
Anyway, I did ask:
Which was basically me asking for clarification. My first sentence was a
(lame) attempt at making the mail a bit more 'friendly' (hence the smiley)
)I replied in the way I did because there was no-way to answer your original
question without simply guessing what you actually wanted.
Your clarification asks your question much better
n!
N
n!
Once an interface has been published it may never be changed or
You cannot avoid this by not using an interface. Your class definitions are
*all* contracts and claim 'I provide this' by their exposed methods and
properties. If your class changes it can still break other code (depending
on the changes you make).
In C# an interface defines a set of methods, and a class may implement
multiple interfaces. An abstract class is similar in principle but you may
not inherit multiple abstract classes (and abstract classes may provide
implementation details, whereas interfaces may not). So by defining an
interface, it allows a future object (ie. one unconsidered during initial
development) to implement it and interact with the old framework (a bit
ambiguous, by 'framework' I mean 'the old code'). Allowing the system to be
forward compatible. As Andreas said, changing this interface breaks the rest
of the code because adding\removing a method invalidates their
implementation. This is ok during initial development when the interface is
new and being tested, but not when the interface has matured and many
classes are implementing it (and maybe even classes you have no control
over).
By providing such a contract *without* interfaces (ie, an abstract [or
other] base class) you are limiting the extensibility of the code. Saying
that though, if your set of code isn't a 'mixin' set of methods\properties.
Or you want to provide some base functionality then an abstract [or other]
base class may be more suitable, which is a design time decision. However
certain changes to such classes may *still* break classes that inherit them
so you do not avoid 'all this fuss'
n!
You cannot avoid this by not using an interface. Your class definitions are
*all* contracts and claim 'I provide this' by their exposed methods and
properties. If your class changes it can still break other code (depending
on the changes you make).
In C# an interface defines a set of methods, and a class may implement
multiple interfaces. An abstract class is similar in principle but you may
not inherit multiple abstract classes (and abstract classes may provide
implementation details, whereas interfaces may not). So by defining an
interface, it allows a future object (ie. one unconsidered during initial
development) to implement it and interact with the old framework (a bit
ambiguous, by 'framework' I mean 'the old code'). Allowing the system to be
forward compatible. As Andreas said, changing this interface breaks the rest
of the code because adding\removing a method invalidates their
implementation. This is ok during initial development when the interface is
new and being tested, but not when the interface has matured and many
classes are implementing it (and maybe even classes you have no control
over).
By providing such a contract *without* interfaces (ie, an abstract [or
other] base class) you are limiting the extensibility of the code. Saying
that though, if your set of code isn't a 'mixin' set of methods\properties.
Or you want to provide some base functionality then an abstract [or other]
base class may be more suitable, which is a design time decision. However
certain changes to such classes may *still* break classes that inherit them
so you do not avoid 'all this fuss'
n!
G
Guest
Hi Marius
----- Marius Horak wrote: ----
Andreas
n! did not ask me to clarify my question. He/she just did not like it
I can bet that he/she does not do it everytime so his/her action (reaction
is selective
I'm sorry, but n! didn't give that impression to me. He was just pointing out that your question is too vague. I also think that your question is too vague
Why I asked the question
Well, I have to maintain an old system where most of objects are based o
interface
In one case I have to add a new parameter to one of the methods
This interface is used as base for 42 objects but the change is relevant t
one object only
Then your interface is not designed well. If a change to an interface is only good for one specific part of a program, and uesless for the rest, consider breaking up the interface in several smaller interfaces, each with a consistent logically grouped set of methods. As a guideline, your interface should not contain a lot of methods and each method should be logically consistent with the others
Without interface all would be simple as the method is referenced by th
object 7 times. With interface I face changing 411 lines adding useles
parameter or to create a separate object that will be 99% like other 4
objects
How would you solve this problem without interfaces
Having this experience I will never use interface in my code
Rather odd. Perhaps you are using interfaces where you shouldn't. Have you thought about that
M
Cheer
----- Marius Horak wrote: ----
Andreas
Andreas HÃ¥kansson said:
n! did not ask me to clarify my question. He/she just did not like it
I can bet that he/she does not do it everytime so his/her action (reaction
is selective
I'm sorry, but n! didn't give that impression to me. He was just pointing out that your question is too vague. I also think that your question is too vague
Why I asked the question
Well, I have to maintain an old system where most of objects are based o
interface
In one case I have to add a new parameter to one of the methods
This interface is used as base for 42 objects but the change is relevant t
one object only
Then your interface is not designed well. If a change to an interface is only good for one specific part of a program, and uesless for the rest, consider breaking up the interface in several smaller interfaces, each with a consistent logically grouped set of methods. As a guideline, your interface should not contain a lot of methods and each method should be logically consistent with the others
Without interface all would be simple as the method is referenced by th
object 7 times. With interface I face changing 411 lines adding useles
parameter or to create a separate object that will be 99% like other 4
objects
How would you solve this problem without interfaces
Having this experience I will never use interface in my code
Rather odd. Perhaps you are using interfaces where you shouldn't. Have you thought about that
M
Cheer
G
Guest
Very simple, if you don't like interfaces, rewrite the code.
If you don't like my responce, don't bother to use your brain and respond,
just press the delete button if is not too much effort.
If you are polite to people, then they will respond polite too.
If you have to edit this many lines of code then that only means that the
original code is used in a "wrong" way to create interfaces and not in the
OOP way.
We are talking about a design fault here from the original programmer! He
simply did not understand enough about interfaces when he started creating
this.
The design of interfaces tells you that you have to duplicate the code and
assign a new ID to that interface to add the new function.
This is why you will find many documenst describing interfaces like this:
IMyInterface, IMyInterface2, IMyInterface3....
Interface does not contain code but maps external published functions to
inside published functions similar like dll entry points.
You are probably one of those designers that perfer to stick in a DOS
console way of programming, but the bad news is that DOS is getting outdated
fast.
You have a choice, evolve or get extinct.
For your information, the world is evolving to .NET so interfaces are also
old technology. Better to start learning the new stuff now. It takes a few
years to get to learn how to use it. Unless you want to sell DOS PC's.
If you don't like my responce, don't bother to use your brain and respond,
just press the delete button if is not too much effort.
If you are polite to people, then they will respond polite too.
If you have to edit this many lines of code then that only means that the
original code is used in a "wrong" way to create interfaces and not in the
OOP way.
We are talking about a design fault here from the original programmer! He
simply did not understand enough about interfaces when he started creating
this.
The design of interfaces tells you that you have to duplicate the code and
assign a new ID to that interface to add the new function.
This is why you will find many documenst describing interfaces like this:
IMyInterface, IMyInterface2, IMyInterface3....
Interface does not contain code but maps external published functions to
inside published functions similar like dll entry points.
You are probably one of those designers that perfer to stick in a DOS
console way of programming, but the bad news is that DOS is getting outdated
fast.
You have a choice, evolve or get extinct.
For your information, the world is evolving to .NET so interfaces are also
old technology. Better to start learning the new stuff now. It takes a few
years to get to learn how to use it. Unless you want to sell DOS PC's.
A
Andreas Håkansson
This is were you loose me? .NET wont make interfaces obsolete since they
are an intrical part of any OOP based environement (like .NET). Perhaps
you ment to say ".NET is here to stay and interfaces are a part of it - time
to learn" ? =)
//Andreas
M
Marius Horak
I see your point.
My background is Delphi (8 years) where polymorphism realy does not exist.
I went through the whole project, there are 86 objects based on interfaces.
Only one is based on two but none other object is based on those interfaces.
It means that basically all is pure inheritance.
Such style of programming I can only call 'programming for the sake of OOP
theory'.
Maybe one day I will find use for polymorphism in my systems.
So far I'm happy with simple inheritance.
MH
My background is Delphi (8 years) where polymorphism realy does not exist.
I went through the whole project, there are 86 objects based on interfaces.
Only one is based on two but none other object is based on those interfaces.
It means that basically all is pure inheritance.
Such style of programming I can only call 'programming for the sake of OOP
theory'.
Maybe one day I will find use for polymorphism in my systems.
So far I'm happy with simple inheritance.
MH
D
Daniel Billingsley
This seems to me to nail it.
You should not conclude that there's something inherently flawed about
interfaces from an example that misuses them.
consider breaking up the interface in several smaller interfaces, each with
a consistent logically grouped set of methods. As a guideline, your
interface should not contain a lot of methods and each method should be
logically consistent with the others.
You should not conclude that there's something inherently flawed about
interfaces from an example that misuses them.
only good for one specific part of a program, and uesless for the rest,TT (Tom Tempelaere) said:
consider breaking up the interface in several smaller interfaces, each with
a consistent logically grouped set of methods. As a guideline, your
interface should not contain a lot of methods and each method should be
logically consistent with the others.
M
Marius Horak
Olaf,
Do not worry about me, I have no financial needs to work.
I do what I do just not to get bored.
I can give up it today. Just my wife is earning so much (3 times what I get)
that she does not want to give up.
And I believe that if one cannot answer the question than one should keep
quiet.
MH
M
Marius Horak
OK, fun is over.
Go back to work (I mean you, I'm going home, it's after 16:00).
MH
Go back to work (I mean you, I'm going home, it's after 16:00).
MH
A
Andreas Håkansson
Marius,
Your question was as close to "What is the meaning of life" as
possible when talking programming
Adding context to it actually
makes it possible to reply to =)
//Andreas
Your question was as close to "What is the meaning of life" as
possible when talking programming
Adding context to it actuallymakes it possible to reply to =)
//Andreas