OOP Flawed paradigm
====================
OOP solves problems by modelling them,but i think
it stops at the noun level,at the verb[action]
level a lot more is expected.

e.g
supposing i'm creating a video game with
an action hero who's suppose to be able to drive
any vehicle he comes accross,

my code should read like english.

to force all vehicles under one type i'll implement
interface
Vehicle.
all vehicles will implement this interface.

i expect one action of all vehicles .
and this is where the problem begins,
while different vehicles can be grouped under one
type.
or under one ESSENCE.
all actions cannot be captured with one general
word.
even when other vehicles have different names,
they still adhere to one TYPE [vehicle]
but not so with the actions they are expected to perform.


lets say the hero has these vehicles to drive in the game:


An Aeroplane,
A car,
A truck,
A canoe,
A rocket,
A bicycle
A motorbike,


to minimize code the ideal would be : implement
one interface, concretize one method.



so car , aeroplane, helicopter, boat,etc would
implement interface VEHICLE
and fill in the drive method.

but the 'drive()' doesnt fit all classes of vehicles.
while all the machines are VEHICLES,not all vehicles
are operated
driven with the 'drive()' word.

u dont drive a plane
u dont 'drive' a canoe.
u dont 'drive' a bicycle.
u dont 'drive' a rocket.
u dont 'drive' a motorcycle.

u 'drive' a truck and a car.
so the general action word doesnt fit all classes of vehicles. working around this shortfall would mean
introducing more code, and more type-checking,
more 'if - else''s and more type creation.
when in the real world, its perfectly understood
that though the 'actions' have different names
they have the same essence.

more interfaces could be created: like,
interface Four_Wheeler, interface Air_Borne,
interface Sea_Vehicle, etc.

But what are all these interfaces trying to address,
- THE METHOD NAME,
Four_wheeler would hold an appropriate abstract
method name like 'drive'
Air_borne would hold an abstract method name
like 'fly'
Sea going would hold an abstract method name
like 'steer,paddle'
etc.But even then some action name's would still be inappropriate
after creating so many forks of the same interfaces.
e.g
you fly an aeroplane, but u dont fly a rocket!
both are still [clumsily] air borne.
ok. to address this name problem we create
anoda interface [it's getting clunky here]
interface Space_borne {}
and give it a more appropriate name 'launch' etc

how about the method or class created to use a vehicle
type.
it takes on generic type - VEHICLE,
and calls a generic method - which one ?

with so many vehicle types and so many method,
it resorts to type checking.

if Four_wheeler type -(drive())
else if
Sea_going type - (paddle or steer etc())
else if
Air_borne type - (fly())
else if
Space_borne type -(launch())
else if Two_Wheeler type - (pedal,ride())

so much type checking.

when the ideal code should have read.
Take a vehicle type.
and call any action that in essence
does the same thing,with different names.

so, at the noun level its easy to create
a machine that is in essence a vehicle though
it may have a different name,

at the action level,
one should be able to create any action
that is in essence
a 'driving action'

e.g
Aeroplane implements Vehicle{

fly [some keyword] drive(){}
fly extends the 'drive' so fly is a type of
'drive'!
}
Canoe implements Vehicle{

paddle [keyword] drive(){}
}

Rocket implements Vehicle{
launch [keyword] drive(){} }

MotorCycle implements Vehicle{
ride [keyword] drive(){}
}
and so on ,
the consumer class or method just calls drive.
and whatever form of drive in the subclass is called
no more type checking. less code, less SHOE HORNING,
no more massaging method names etc.
no meaningless,more abstract method names.

consumerMethod(Vehicle v){
v.drive();// whatever form it takes, it
get's driven,
The action hero does his thing.
}

it could be argued that a more abstract method name
could be used,but such names dont perfectly suit
the 'real world' OOP tries to model.
e.g 'operate' , 'move' could be used. but this names unsuitably describe the intended action.
i.e to 'drive' the vehicle.

You could simply declare a move() function in the vehicle interface. Problem solved.

@fallguy, I think the problem is not in OOP but in how we use OOP. A good way out is to remove the parts that
don't fit into "mould" and implement them seperately. You can use a design pattern called "Strategy". I think
at some point OOP programmers need some understanding of design patterns. It's a way of extending OOP and
making it work in situation where it may normally seem difficult or impossible.
Do some googling on "Design Patterns"

You may want to try using Abstract classes in place of interfaces too. I mean an interface is simply a contract class to start that all objects that inherit it will implement it. Yes. Design patterns would be a good way to go. Now the main thing to understand about OOP in the case you gave is that it is not necessarily a way to get around coding but like refactoring, a way to better your code and make it more functional and less redundant. As the other fellow gave earlier, in the case of driving, there are so many ways around that.

1) You could declare a move and have it take on two arguements, a start and end destination, now you can go ahead and implement this method in each of your vehicle type objects and basically have each decide how it would accomplish a move from point A to B.

2) You could right all the available modes of locomoting , eg pilot , drive, row, canoe, cycle , in your base class and put the code for each type down there for each object that inherits it to decide which to use,

Design Patterns is a good idea as the other dude hinted , GOF would be a great place to start from.


KoboJunkie

thanks for you understanding, i didnt say i needed help on solving the problem,
like suen said just use a more abstract and unrelated verb -'move'
but in real life do say , i 'moved' the car, i 'moved' the boat - no!! if u said that u'd need clarification,
u'd tell ur puzzled hearer , i mean , i 'cruised ' the ride/car - OOP is meant to model the real world - remember. therefore it should do it right.
ok , think of these,
interfaces, u not that interfaces ,which are nothing but answers to 'actions'
carry ugly implementation details,
if i need just one method in an interface of 20 declared public methods,
i'd have to give the remaining 19 methods blank implementations,
look at java swing for example which uses a lot of interfaces,
most interfaces are just bases for adapter classes,why.
to work with an action ,i.e just 1 out of the many methods,
u have to use two classes, the interface and the adapter classes
that gives blank implementations.
u see the cumbersomeness in dealing with actions coming thru i wont even talk about inner classes
.
if direct dealing with methods could be possible code would be slimmer in OOP - usng java
OOP is poor at dealing at the 'verb' level that why java is a NOUN centric language.
and this centricity makes it cumbersome,
i'm not pointing to a problem with coding but with language specification.
e.g do you notice in C that u save a 'function' by name , u use an action right out of the box,
in OOP its ,full fledged u can't ,u move functions by moving classes.
OOP solves a lot but in code,and software the 'action' scores is the 'worker'
but there is lil freedom at working with methods as they are with working with method containers
i.e the classes .