OO is not that great: many repeated codes

[Shawn]

Hi,

I think OO is not great, compared to procedural languages. Each method
has to be hosted in one class. So the identical method code could be
repeatedly in several classes. I know inheritance /abstract classes/
interface concepts well. But please let me explain my point:

Professor and Student (two classes) know drive car well. So the method

void driveCarWell()

has to be in both classes.

HouseWife and Professor know how to cook. So the method

void cookDeliciousFood()

has to be in both classes.


Professor and Calculator (Two classes) can do some advanced calculation,
say find the average of two integers:

int average(int a, int b)

has to be in both classes.

Now the classes are like the following:

public class Professor
{
void driveCarWell()
void cookDeliciousFood()
int average(int a, int b)

...
}

public class Student
{
void driveCarWell()
...
}

public class HouseWife
{
void cookDeliciousFood()
...
}

public class Calculator
{
int average(int a, int b)
...
}

As you see, methods are repeated in many classes. It is hard to use
inheritance to solve the issue. Particularly, Professor and Calculator
cannot share a superclass in real world. And in Java, there is no
multiple inheritance.

In procedural language, you only need to write the method once and put
them in the global place. Then you can grab them anytime you want.
Because a method don't need to be buried inside a class.

Thank you very much for your feedback.

 

[Thomas Weidenfeller]

I think OO is not great, compared to procedural languages.

Then use one of these languages. F'up set.

 

[Oliver Wong]

Hi,

I think OO is not great, compared to procedural languages. Each method has
to be hosted in one class. So the identical method code could be
repeatedly in several classes. I know inheritance /abstract classes/
interface concepts well. But please let me explain my point:

Professor and Student (two classes) know drive car well. So the method

void driveCarWell()

has to be in both classes.

HouseWife and Professor know how to cook. So the method

void cookDeliciousFood()

has to be in both classes.


Professor and Calculator (Two classes) can do some advanced calculation,
say find the average of two integers:

int average(int a, int b)

has to be in both classes.

Now the classes are like the following:

public class Professor
{
void driveCarWell()
void cookDeliciousFood()
int average(int a, int b)

...
}

public class Student
{
void driveCarWell()
...
}

public class HouseWife
{
void cookDeliciousFood()
...
}

public class Calculator
{
int average(int a, int b)
...
}

As you see, methods are repeated in many classes. It is hard to use
inheritance to solve the issue. Particularly, Professor and Calculator
cannot share a superclass in real world. And in Java, there is no multiple
inheritance.

In procedural language, you only need to write the method once and put
them in the global place. Then you can grab them anytime you want. Because
a method don't need to be buried inside a class.

Thank you very much for your feedback.

Different tools are suited for different jobs. OO is good for a lot of
things, but not everything. Procedural is good for a lot of things, but not
everything. If you're "stuck" in an OO language, and you want to implement a
procedural solution, you can emulate global functions with public static
methods.

- Oliver

 

[bugbear]

Hi,

I think OO is not great, compared to procedural languages. Each method
has to be hosted in one class. So the identical method code could be
repeatedly in several classes. I know inheritance /abstract classes/
interface concepts well. But please let me explain my point:

Professor and Student (two classes) know drive car well. So the method

void driveCarWell()

has to be in both classes.

HouseWife and Professor know how to cook. So the method

void cookDeliciousFood()

has to be in both classes.


Professor and Calculator (Two classes) can do some advanced calculation,
say find the average of two integers:

int average(int a, int b)

has to be in both classes.

Now the classes are like the following:

public class Professor
{
void driveCarWell()
void cookDeliciousFood()
int average(int a, int b)

...
}

public class Student
{
void driveCarWell()
...
}

public class HouseWife
{
void cookDeliciousFood()
...
}

public class Calculator
{
int average(int a, int b)
...
}

As you see, methods are repeated in many classes. It is hard to use
inheritance to solve the issue. Particularly, Professor and Calculator
cannot share a superclass in real world. And in Java, there is no
multiple inheritance.

Nicely rigged example.

If, however, we created a class called "cooking skills"
which contains 27 methods, and 4 fields, it suddenly looks
much more reasonable for a person to "HAVE" cooking
skills (the difference between "has a" and "is a" in OO design)

ditto for maths and driving.

BugBear

 

[mordicus]

Hi,

I think OO is not great, compared to procedural languages. Each method
has to be hosted in one class. So the identical method code could be
repeatedly in several classes. I know inheritance /abstract classes/
interface concepts well. But please let me explain my point:

Professor and Student (two classes) know drive car well. So the method

....

Hum, ok.

public class Driver {
public Driver() {}
public void drive{
}
....
}

public class Cooker {
public Cooker() {}
public void cook{
}
....
}

public class Professor
{
Cooker cooker;
Driver driver;
public Professor() {
cooker = new Cooker();
driver = new Driver();
cooker.cook();
driver.drive();
}
}

public class Student
{
Cooker cooker;
Driver driver;
public Student() {
cooker = new Cooker();
driver = new Driver();
cooker.cook();
driver.drive();
}
}


So, my student and my professor know how to drive and cook, but my car don't
know how to cook... i don't see the problem...

 

[Shawn]

Hum, ok.

public class Driver {
public Driver() {}
public void drive{
}
....
}

public class Cooker {
public Cooker() {}
public void cook{
}
....
}

public class Professor
{
Cooker cooker;
Driver driver;
public Professor() {
cooker = new Cooker();
driver = new Driver();
cooker.cook();
driver.drive();
}
}

public class Student
{
Cooker cooker;
Driver driver;
public Student() {
cooker = new Cooker();
driver = new Driver();
cooker.cook();
driver.drive();
}
}


So, my student and my professor know how to drive and cook, but my car don't
know how to cook... i don't see the problem...

Great. I like your solution very much. Thank you all for your help. They
are very helpful.

 

[Mark Rafn]

I think OO is not great, compared to procedural languages. Each method
has to be hosted in one class. So the identical method code could be
repeatedly in several classes.

Then you're not using inheritance or encapsulation correctly.

I know inheritance /abstract classes/
interface concepts well. But please let me explain my point:

Professor and Student (two classes) know drive car well. So the method
void driveCarWell()
has to be in both classes.

Ah, you're arguing for multiple inheritance. I agree with you. It should be
easier than it is to have a Driver base class _AND_ an Academic base class,
and Professor should have properties and methods from both, overriding some as
needed.

In procedural language, you only need to write the method once and put
them in the global place.

Sure, but THEN you have to deal with the namespace question, and the ownership
question. If Professor and Housewife can both readBook(), but they do so in
wildly different ways, you completely lose the ability to encapsulate those
specifics.

Thank you very much for your feedback.

Use the right tool for the job, and for most complex systems, OO is a big win,
even when it's not a perfect fit for your conceptual model. You're often (not
always) better off making sure your model fits what can be developed than
throwing out encapsulation entirely.

 

[Greg Bittar]

Hi Shawn. What I would do is take a step back. Given the breadth of
your model, it looks like you have to define a Person object, which will
be associated with zero, one, or more of the following:

DriverRole object
CookRole object
ProfessorRole object
StudentRole object
WifeRole object

or something like that. You are talking about dissimilar roles that a
person can fulfill.

Of course, there are cases where more than one class will implement the
same method (enabling polymorphism), but if they simply duplicate each
other's code, maybe that's an indication you should abstract
functionality away into a new class.

Ironically, your analysis stems from a procedural interpretation of what
OO is about. It's helpful to differentiate classes as you would factor
tables in an RDMBS. Tip: the whole thing with OO is that the code goes
with the data.