How to represent OOP concepts in algorithms in a standard way?

Question

I have usually been using the Cormen algorithm format to teach some introductory courses in Programming. I mean something like this:

TreeSearch(k,n)
1. if x==NIL or k==x.key
2.     return x
3. if k<x.key
4.     return TreeSearch(k.left,n)
5. else return TreeSearch(k.right,n)

Actually I have not agree with a couple of lecturers in my institution that they insist to put the type of the variable that they are using in the algorithm. I mean, to do that, will it not be to make a bias toward the programming language and not to focus on the algorithm? For example what would happen if the student grab other programming language, like R or Python, that really do not care about the type of variable.

The other issue that I have is how to represent OOP algorithms in a nice algorithmic way. For example when I make a constructor should I put something like:

Class: car
Attributes: wheels
Constructor car()

or something like

Class: car
Function car()

also when I come to the part of inheritance, one of my colleages put the word super() to define inheritance in an algorithmic way, but again I think that is too Java-way to do this part. Usually they teach in that way because the practical part is made in Java, but again I think that the algorithm should be more freely, directly towards the logic, and not to an specific programming language.

Does anybody knows some standard to represent algorithms for OOP?

Answer 1

Generally there is no unified to present algorithms. Each researcher should use/introduce notation with which he is most comfortable with.

If you look at some algorithmic books writers have different approach to this manner.

For instance:

• CLRS book gives no types for functions arguments
• Tel's "Introduction to distributed algorithms" gives types
• Sedgewick's "Algorithms" gives code in Java (which is not very good solution IMO)

On the other hand any object can be represented as tuple of base data types, eg binary tree can be presented as:

(5,(3,(1,NIL,NIL),(4,NIL,NIL)),(6, NIL, NIL))

Which might corresponds to

5
|\
3 6
|\
1 4

But the first notation is not very readable, so its easier to relate so such tuple as Node.

Additionally algorithms representation depends on field on which they are presented. If you assume that algorithm should be more or less translatable from pseudo code to actual code then you should introduce hints and notation to your algorithm presentation which allow this. But if that is not the case and you want to focus mainly on algorithm idea, or some other complexity value then, time then mathematical notation might become handy. In the end as previously stated it depends on needs.

If you look closely on various papers and books you can see that types of arguments are either obvious from context, or explained in algorithm description.

I suggest you to get familiar with $\LaTeX$ Algorithms module.