Re: Program to an Interface not an implemetation

raxitsheth@xxxxxxxxx schrieb:
> Will wrote:
[snip]
>>Most real world abstracted classes are riddled with
>>their own particular foibles which makes
>>finding commonality a nightmare.
>
>
> Two class might not be Exactly Simmilar but if they are related, there
> are most chances to have Common properties/Functionality....you can use
> them to make interface
>

Hi Will,

Just to provide one example:
Even since cars are very different, nearly every Person who has a
driving licence can drive a car.
Here please note one think: Even in the language we *must* use an
abstraction, which is kind of a interface for me. We can not say: Every
Person who has a driving licence can drive AND THEN EVERY TYPE OF WHAT
HE CAN DRIVE.

Even if steering, gear switching and so on is different, here you want
do use an interface (if you are Java programmer note that interface in
the GoF doesn't mean a Java Interface, it can be an Abstract class too),
so every person with a driving lizence can easily sit in your app-cars
and drive.

Here there might be also a good thing to have f.e. a strategy maybe?:

// pseudo-code, very near on Java i think @_@

// still these example is made easy, but i am at home right now, and I
can't provide a real world, although you have sources from the brevious
poster, however, you might get the idear

class LicenceDrivableInterface {
void steer(Direction direction);
void switchGear(int gear);
bool isAutomatic();

// other driving methods

}

class RoundWheelAutomaticDrivable extends LicenceDrivableInterface {
void steer(direction direction) {
if(direction.direction == left)
wheel.steerLeft(direction.persentage);
if(direction.direction == right)
wheel.steefRight(direction.persantage);
}

void switchGear(int gear) {
if(gear == 0)
gear.stop();
else if(gear == 1)
gear.drive();
//....
}

bool isAutomatic() {
return true;
}
}

class RoundWheel5GearsDriveable extends LicenceDrivableInterface {
// steer same a above

void switchGear(int gear) {
if(gear < 0 || gear > 5)
SuperErrorStuff();
gear.switchGear(gear);
}
}

class Car {
protected LicenceDrivableInterface driveable_interface;

void steerCar(Direction direction) {
driveable_interface.steer(direction);
}
void switchGear(int gear) {
driveable_interface.switchGear(gear);
}

// other driving methods
}

class Volvo extends Car { // i don't know, but I know some Volvos with
automatic, so I hope that fits....

public Volvo() { // CONSTRUCTOR
driveable_interface = new RoundWheelAutomaticDrivable();
}
}

class Skoda extends Car {
public Skoda() {
driveable_interface = new RoundWheel5GearsDriveable();
}
}



So what did that bye us for a driver, you might ask? He still needs do
know how to steer a car with or withoud automatic. So there are some
things: First for all cars with the same geer and/or the same kind of
steering you can easier maintain changes.

Second it is too easier for a person:
steering might always be the same (untill you introduce Joystics for
driving), and switching is resolft too more easily with a strategy
pattern [I am not a fan of that pattern, I just invented this example,
and it turend out this occured often...].

// note that the way the user tellt the different strategis his
intention whant work that way, I think, its just an idear...

class SwitchingInterface {
void switch();
}

class SwitchAutomatic extends SwitchingInterface {
void switch(Intention intention) {
if(intention.wantDrive())
car.switchGear(1);
if(intention.wantDriveFast())
car.switchGear(1); // no change here
//...
}
}

class Switch5Gear extends SwitchingInterface {
void switch() {
if(intention.wantDrive())
car.switchGear(1);
if(intention.wantDriveFaster())
car.switchGear(2);
}
}

class Driver {
protected SwitchingInterface switching_behavior;

getInCar() {
if(car.isAutomatic)
switching_behavior = new SwitchAutomatic();
else
switching_behavior = new Switch5Gear();
}
switch(Intention intetion) {
switching_behavior.switch(intetion);
}

drive() {
switching_behavior.switch(new Intetion("Want Drive");
car.steerCar(new Direction(left, 10%);
}
}

So what was my intention whith the code:
With design principles and patterns it is possible to modell differend
behvior and other differences, but still provide similarities. There
INCREASES maintainability, because you have less places to change. If
the code then is well documented, you have a much clearer modell, ane
then the reverse is true: it is easier to understand.

However you are right that overengineering is not good, and if there are
no common things, than there is no need to make an interface, untill it
is not important to follow the open/closed principle vor the
sourrounding classes.

Jörg

Hope this was an idear.
Jörg
.