CODEWITHSUNDEEP
rust
Guilherme Amorim
Guilherme Amorim

Reputation: 445

How can I make this Rust code more idiomatic

Recently I started to learn Rust and one of my main struggles is converting years of Object Oriented thinking into procedural code.

I'm trying to parse a XML that have tags that are processed by an specific handler that can deal with the data it gets from the children.

Further more I have some field members that are common between them and I would prefer not to have to write the same fields to all the handlers.

I tried my hand on it and my code came out like this:

use roxmltree::Node; // roxmltree = "0.14.0"

fn get_data_from(node: &Node) -> String {
   let tag_name = get_node_name(node);
   let tag_handler: dyn XMLTagHandler = match tag_name {
      "name" => NameHandler::new(),
      "phone" => PhoneHandler::new(),
      _ => DefaultHandler::new()
   }
   if tag_handler.is_recursive() {
     for child in node.children() {
         let child_value = get_data_from(&child);
         // do something with child value
     }
   }
   let value: String = tag_handler.value()

   value
}

// consider that handlers are on my project and can be adapted to my needs, and that XMLTagHandler is the trait that they share in common.

My main issues with this are:

Upvotes: 1

Views: 351

Answers (1)

trent
trent

Reputation: 27915

  • This feels like a Object oriented approach to it

Actually, I don't think so. This code is in clear violation of the Tell-Don't-Ask principle, which falls out from the central idea of object-oriented programming: the encapsulation of data and related behavior into objects. The objects (NameHandler, PhoneHandler, etc.) don't have enough knowledge about what they are to do things on their own, so get_data_from has to query them for information and decide what to do, rather than simply sending a message and letting the object figure out how to deal with it.

So let's start by moving the knowledge about what to do with each kind of tag into the handler itself:

trait XmlTagHandler {
    fn foreach_child<F: FnMut(&Node)>(&self, node: &Node, callback: F);
}

impl XmlTagHandler for NameHandler {
    fn foreach_child<F: FnMut(&Node)>(&self, _node: &Node, _callback: F) {
        // "name" is not a recursive tag, so do nothing
    }
}

impl XmlTagHandler for DefaultHandler {
    fn foreach_child<F: FnMut(&Node)>(&self, node: &Node, callback: F) {
        // all other tags may be recursive
        for child in node.children() {
            callback(child);
        }
    }
}

This way you call foreach_child on every kind of Handler, and let the handler itself decide whether the right action is to recurse or not. After all, that's why they have different types -- right?

To get rid of the dyn part, which is unnecessary, let's write a little generic helper function that uses XmlTagHandler to handle one specific kind of tag, and modify get_data_from so it just dispatches to the correct parameterized version of it. (I'll suppose that XmlTagHandler also has a new function so that you can create one generically.)

fn handle_tag<H: XmlTagHandler>(node: &Node) -> String {
    let handler = H::new();
    handler.foreach_child(node, |child| {
        // do something with child value
    });
    handler.value()
}

fn get_data_from(node: &Node) -> String {
    let tag_name = get_node_name(node);
    match tag_name {
        "name" => handle_tag::<NameHandler>(node),
        "phone" => handle_tag::<PhoneHandler>(node),
        _ => handle_tag::<DefaultHandler>(node),
    }
}

If you don't like handle_tag::<SomeHandler>(node), also consider making handle_tag a provided method of XmlTagHandler, so you can instead write SomeHandler::handle(node).

Note that I have not really changed any of the data structures. Your presumption of an XmlTagHandler trait and various Handler implementors is a pretty normal way to organize code. However, in this case, it doesn't offer any real improvement over just writing three separate functions:

fn get_data_from(node: &Node) -> String {
    let tag_name = get_node_name(node);
    match tag_name {
        "name" => get_name_from(node),
        "phone" => get_phone_from(node),
        _ => get_other_from(node),
    }
}

In some languages, such as Java, all code has to be part of some class – so you can find yourself writing classes that don't exist for any other reason than to group related things together. In Rust you don't need to do this, so make sure that any added complication such as XmlTagHandler is actually pulling its weight.

  • is_recursive needs to be reimplemented to each struct because they traits cannot have field members, and I will have to add more fields later, which means more boilerplate for each new field

Without more information about the fields, it's impossible to really understand what problem you're facing here; however, in general, if there is a family of structs that have some data in common, you may want to make a generic struct instead of a trait. See the answers to How to reuse codes for Binary Search Tree, Red-Black Tree, and AVL Tree? for more suggestions.

  • I could use one type for a Handler and pass to it a function pointer, but this approach seems dirty

Elegance is sometimes a useful thing, but it is subjective. I would recommend closures rather than function pointers, but this suggestion doesn't seem "dirty" to me. Making closures and putting them in data structures is a very normal way to write Rust code. If you can elaborate on what you don't like about it, perhaps someone could point out ways to improve it.

Upvotes: 1

Related Questions