# Linked lists - Two ways of writing the same thing?

I am on “Linked List Implementation III” exercise:

For the code written at the bottom the given solution is:

def remove_node(self, value_to_remove): current_node = self.get_head_node() if current_node.get_value() == value_to_remove: self.head_node = current_node.get_next_node() else: while current_node: next_node = current_node.get_next_node() if next_node.get_value() == value_to_remove: current_node.set_next_node(next_node.get_next_node()) current_node = None else: current_node = next_node

The code I wrote (which was accepted, and seems to work the same) is:

def remove_node(self, value_to_remove): current_node = self.head_node if current_node.value == value_to_remove: self.head_node = self.head_node.next_node else: while current_node: next_node = current_node.next_node if next_node.value == value_to_remove: current_node.set_next_node(next_node.next_node) current_node = None else: current_node = current_node.next_node

These are my queries:

Writing something like ‘next_node = current_node.next_node’ or ‘next_node = current_node.get_next_node()’ seems to be the same. In the first i am referencing the next_node value of current_node, in the second I am using current_node’s get_next_node function to return the same value. Am I thinking about this correctly? Are the outcomes the same? I feel like I’m missing something very obvious because otherwise defining getter functions seems redundant.

Thank you for any help

Hi,

Your question centers on OOP principles. Within that framework (OOP) private data members are only reached indirectly through methods, so the method call is technically “more” correct. However, the way the problem is laid out the guideline is not specified (and, the data members are not actually defined as private explicitly, which would often be a case if it were pure OOP). With that in mind, your answer is perfectly good.

3 Likes

Would you consider `private` members to be essential to the definition of OOP? I know the definition wobbles a little but would be a typical comp sci view of it?

1 Like

It’s an interesting question!

Informally (since I’m citing wikipedia):
All the definitions of encapsulation I find talk about restricting access… and I do feel encapsulation is a characteristic OOP principle. So in that case `private` members would be essential.

For example

encapsulation refers to the bundling of data with the methods that operate on that data, or the restricting of direct access to some of an object’s components.[1] Encapsulation is used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods. from wiki

2 Likes

Ta, didn’t mean to put you on the spot but it’s appreciated. I suppose I’ve not put too much thought on what actually makes it object-oriented, at least in a stricter sense, and I found myself scratching my chin when you mentioned it. Will have to do a bit of reading but from the Wikipedia article I’m finding myself in agreement with you at this point.

2 Likes

Oh yea, no worries. I guess I don’t think about it too much since it’s basically built-in to C++ practice (which I wouldn’t want to conflate with OOP blindly). And even though good practice can be a controversial thing at times (particularly with C++) I think it’s still good to reflect on these things (for me) insofar as they serve as a blueprint to reason about design structures.

2 Likes

Thank you for the responses! I get the gist of it, but I don’t think I’ll fully understand until I learn a bit more. Will look up private members and encapsulation today.

Finding situations like these very interesting, just wish (from a noobs point of view) that things like these were addressed directly during the exercises to reinforce good coding practice, as if one isn’t always looking further into most exercises things like this can be easy to miss. But I guess the looking further part is something that should be done anyways to help learn.

1 Like

I’ve always thought Python’s a bit of a funny one to introduce nodes in since the standard `obj.attribute` dotted look-up for attributes via `.__getattribute__` allows public access by default (which makes using getter methods like this instead of direct access less intuitive). Still, probably easier than throwing a second language into the mix and slightly less verbose syntax than some.

I posted a reply to a similar question recently that might be useful, it links to a stackoverflow page where folks discuss the merits/drawbacks of using accessors for data like this along with another for the standard alternative accessor solution in Python, using properties.

At the end of the day though you’ll have to stick to the way the lessons do this for now as that’s the way the tests are also set-up.

2 Likes

I’ll add to @tgrtim’s great comment:

If you’re doing a technical interview in python, the way you did it is the most natural way, unless it’s a listing that’s oop-specific. I’ve had this happen where they ask me things particularly centered on OOP design. I would just ask if it’s ok to write it the simple way for brevity.

Paradigm-specific topics are tricky business. For me, personally I prefer an agnostic approach to data structures and algorithms that way you can just focus on the topic. Then in any case you can pick up a given paradigm and apply the implementation from there. That being said, it’s pretty useful to at least be aware of OOP (in terms of working). For individual projects it’s possible to avoid it completely.

2 Likes