Inteface (and life) sucks

  • Thread starter Thread starter Marius Horak
  • Start date Start date
M

Marius Horak

I've never used Interface and never will.
But now I have to make major modifications to a large system where
almost all classes are based on some kind of Interface. Hundreds of
classes.
When I want do add a new property or method I have to modify the
interface and next I have to modify dozens of other classes or create
new inteface.
Sooner or later I will finish having a single class based on its own
interface. So what is the point of using Interface?

Madness.

MH
 
loool Marius i understand your frastration,
Interfaces are used for two reasons
1. when you build a COM object you need the interfaces to be able to use the
code from other languages (ex vb6, c++, etc) that don't understant what the
hell a class is but the know interfaces.
2. if you build an interface for wrapping a database table, and add the
method save to it, then as many classes you have for the different tables in
your db, you only have to call Interface.Save();
so insdead of knowing in your code, what sort of table class you have to use
you treat the object as an interface and get rid of the if and buts of the
code.
Also by building interfaces you have a more efficient view of your model, if
you don't use UML to model your project before start writting any code.
P.S. If you do a change in the interface just go to the classes the
impliment it and add the implement again :
public class SomeCLass (: MyInterface) <-- delete this part and write it
again, and will build a region with the properties and methods that you just
add
hope that help
 
Try :
http://msdn.microsoft.com/library/d.../vbcon/html/vboriInterfaceAbstractClasses.asp

The "interface" just define the "contract" that the class should fullfill to
be usable (throught this interface). It doesn't deal at all with
implementation details.

In .NET for example the IComparable interface would allow compare a class
instance with another class instance. You can't provide a default
implementation as each class would implement its own specific comparison
criteria plus the functionaly exposed by this interface is totally a
different thing than the main goal of the class...
 
Patrice said:
In .NET for example the IComparable interface would allow compare a
class instance with another class instance. You can't provide a
default implementation...
Click to expand...

Yes, can, it wil return 0;
But my point is that when it comes to heavy modification of a large
system Interface (and to some extend abstarct classes) is pain in neck.


MH
 
Nassos said:
1. when you build a COM object you need the interfaces to be able to
use the code from other languages (ex vb6, c++, etc) that don't
understant what the hell a class is but the know interfaces.
Click to expand...

I think you got point here.
2. if you build an interface for wrapping a database table, and add
the method save to it, then as many classes you have for the
different tables in your db, you only have to call Interface.Save();
Click to expand...

I think I can get the same without Interface.

Anyway, I will stick to my way of programming - NO F**Y INTERFACE.
I call it "coding for idiots", so any idiot can maintain my code.
Remember, 10% of costs is development, 90% maintenance.

Well, I feel better now.

We have another system, it's now Version 3.
Version 1 was ditched as it was to expensive to modify it.
Version 3 was written by a different team and is no better than Version
1 so our company decided to stick to Version 2.
All programmers involved in creating three versions were v.good coders
who were competing with each other who is a better DotNet programmers
(they wanted to impress bosses). Just the finish product is crap.
Funny thing, they don't work here any more.


MH
 
IMO would be bad as you wouldn't have a correct result if someone "forgot"
to implement the correct behavior.

A more convincing example could be ICommandDb that is provider dependant and
for which a default implementation would be very likely totally useless :
http://msdn.microsoft.com/library/d.../html/frlrfsystemdataidbcommandclasstopic.asp

Back to your own case, as soon as you code several times the same things in
multiple classes, then it's likelly that a class would be a better fit than
an interface....
 
Marius Horak said:
I've never used Interface and never will.
Click to expand...

That sounds very unlikely to me. Never used IDisposable.Dispose?
But now I have to make major modifications to a large system where
almost all classes are based on some kind of Interface. Hundreds of
classes.
Click to expand...

Excellent. That's a good thing. It encourages loose coupling. You
needn't use interfaces within tightly coupled classes, but where the
coupling *should* be loose, using interfaces helps to keep that
looseness.
When I want do add a new property or method I have to modify the
interface and next I have to modify dozens of other classes or create
new inteface.
Click to expand...
Sooner or later I will finish having a single class based on its own
interface. So what is the point of using Interface?
Click to expand...

1) It allows future implementations to be switched in and out without
any worries about implementation class hierarchy.

2) It makes it clear which parts of a class you are using - one class
may implement several interfaces sometimes, but you often only care
about one of them.

3) It makes unit testing really easy with mock frameworks like
EasyMock.NET - particularly if you're using inversion of control.
 
The later maybe true (well, as far as *my* dealings with Microsoft go)
but the former is not.
I've never used Interface and never will.
Click to expand...

You have missed a lot, then. There are a lot easier to understand if you
regard an interface as a behaviour. So the ICloneable interface means
that an object can be cloned, the ISerializable interface means that it
can be serialised. They say nothing about the implementation and so say
nothing about the class (type) but they say a lot about the what the
implementation does.

Consider this hyperthetical case:

interface IPrintable
{
void Render(PrinterContext ctx);
PaperType PerferredTypeOfPaper{get;}
event PrintedDelegate ItemPrinted;
}

Any class could implement this: Book, Photo, Page, Ticket. The point is
that if a class implements this interface it means it has the
respensibility to render itself to some printer context (say, a
container for a raster image), it has the responsibility to specify the
type of data it prefers to be printed on, and it can be notified that
the printing has completed. The class can do anything else it wants to
do, but it must do all of these things. The user of the interface is
only concerned with the interface's behaviour, it does not care about
anything else the object will do.

Imagine a printer object:

class Printer
{
public PrintItem(IPrintable doc);
}

This does not need to know about the type of the object passed, only
that it has the required behaviour. This gives you polymorphic code
because *any* object that implements IPrintable can be passed to
PrintItem. This is a *huge* advantage and your code will benefit
immensely from using interfaces.
But now I have to make major modifications to a large system where
almost all classes are based on some kind of Interface. Hundreds of
classes.
Click to expand...

If the interfaces are factored correctly then this is great. IIRC the
maximum number of items in an interface is approximately five, if you
have more than that then you know that the interface was not correctly
factored and contains more than one behaviour.
When I want do add a new property or method I have to modify the
interface and next I have to modify dozens of other classes or create
new inteface.
Click to expand...

Argh!!!!! NO NO NO!!!

This is not the way to do things. You should *only* add items to an
interface that are related to the behaviour. If the items represent
another behaviour then they should be in another interface (or possibly,
not in any at all). If the software you have is designed to have
interfaces with huge numbers of properties/methods then it is a poor
application and needs rewriting totally.
Sooner or later I will finish having a single class based on its own
interface. So what is the point of using Interface?

Madness.
Click to expand...


If the application simply has an interface per class then there is no
point in using interfaces. The original developer should be made to
stand waist deep in sewage for soiling the good name of interfaces.

(Oh BTW, some of Microsoft's interfaces are designed very badly, and I
recommend the sewage treatment for those developers too.)

Richard
 
If the application simply has an interface per class then there is no
point in using interfaces. The original developer should be made to
stand waist deep in sewage for soiling the good name of interfaces.
Click to expand...

Ever done unit testing with mock objects? Much easier with interfaces.

Anyway, even if there's only one implementation *now*, that doesn't
mean it's not a good idea to design cleanly for the future.
 
Back
Top