Using OOP with a BST
I haven't really implemented yet, but I have a plan to make a program that uses classes to handle a binary tree. So I'm going to have a "node" class that has the data plus a "left" and "right" pointer. Then I'm planning to have a "tree" class that will handle the placement of the nodes.
My question: is that pretty standard for OOP? I'm completely new to OOP so is there a more "correct" way to handle a BST? I was thinking about having a tree class with a node struct as a data member, but I was told that is not OOP.
My question: is that pretty standard for OOP? I'm completely new to OOP so is there a more "correct" way to handle a BST? I was thinking about having a tree class with a node struct as a data member, but I was told that is not OOP.
That is OO. You have two objects, a tree and a node.
The solution is a correct solution. I'd say you're on the right track.
The solution is a correct solution. I'd say you're on the right track.
What do you need the tree-class for? What operations should it contain?
My first attempt would have only one class, which contains an "add" function that recursively call "add" on its child nodes.
Having a separate "controlling class" and "data class" is considered by many people very un-OOish.
Ciao, Imi.
My first attempt would have only one class, which contains an "add" function that recursively call "add" on its child nodes.
Having a separate "controlling class" and "data class" is considered by many people very un-OOish.
Ciao, Imi.
@imi: It sounds likee flodywan wants to have a seperate class to handle the relationship between the nodes. I had to read this a few times but that is what I gather, please correct me if I am wrong.
It sounds like the "node" could be a struct instead of a class if not for the pointers, but by moving the pointers to the "tree" class, with a function to create new "nodes" then associate them with the parent "nodes" that problem would be solved. It's all about preferance in the end you can try to be compliant but everyone has their peevs.
It sounds like the "node" could be a struct instead of a class if not for the pointers, but by moving the pointers to the "tree" class, with a function to create new "nodes" then associate them with the parent "nodes" that problem would be solved. It's all about preferance in the end you can try to be compliant but everyone has their peevs.
| I was thinking about having a tree class with a node struct as a data member, but I was told that is not OOP. |
together with
| It sounds like the "node" could be a struct instead of a class... It's all about preferance in the end you can try to be compliant but everyone has their peevs. |
Of course, but the OP wants opinion about what preference is more OO-ish ;-).
IMHO, a structure where one class contains plain data but no functions and another class "handles" all the functions for the first class is just not very much object oriented. I'd say it is rather "data oriented" and maybe it works much better when its data oriented.. OO is not a hammer for every nail.
But asked about OO, I'd expect stuff like data encapsulation and type abstractions. Not an attempt to separate data and code. ;-)
So let us turn the question around: Why does it have to be OOP?
Ciao, Imi.
Last edited on
Thanks for the responses. The assignment requires implementing a BST fully with OOP and I've heard from many that using a struct for the node defies the rules of OOP. This brings me to a new question though.
Is OOP a clear-cut thing? It seems like there are differing views whereas procedural programming is pretty clear. Thanks for answering my noob questions!
- flodywan
Is OOP a clear-cut thing? It seems like there are differing views whereas procedural programming is pretty clear. Thanks for answering my noob questions!
- flodywan
OO has atleast two roots, Simula 67 and Smalltalk. The emphases are different and there have always been arguments about what it is to be OO between the two camps. So no, it's not clear cut.
Topic archived. No new replies allowed.