Key points

• The key point is to have a trait to represent both, simple and composed structs.

• Clients should ignore the difference between compositions and individual objects.

• Avoid case statements to specify individual treatment to every struct, making it easier to put new types of components

Participants

Component

An abstract representation of the component

Leaf

The simplest component, which has no children

Composite

The sort of Component which has children

Client

The software part that uses the composite api

Study

In the example I am going to model glasses because I already used them in my professional career and did not have any knowledge of the composite pattern at that time, the final solution was very close to the pattern but I would suffer much less if I knew it.

OO approach

Firstly I will show a possible approach to use as a more OO driven language, such as Java, Kotlin etc

Implemented approach

Secondly, I will show the approach that I choose using rust, because of its differences from the language cited earlier

Code solution

pub trait Item {
    fn price(&self) -> f64;
    fn add_item(&mut self, _: Box<dyn Item>) -> Result<(), &str>{
        return Err("not implemented on a simple item")
    }
    fn remove_item(&mut self, _: usize) -> Result<(), &str>{
        return Err("not implemented on a simple item")
    }
}

I decided to use a default implementation to deal with component children since it would simplify the use for the Composite client. It's important to evaluate the tradeoffs here.

struct ItemComposite {
    items: Vec<Box<dyn Item>>
}

impl ItemComposite {
    fn new() -> Self {
        return ItemComposite{
            items: Vec::new()
        }
    }
}

impl Item for ItemComposite {
    fn price(&self) -> f64 {
        let prices = self.items.iter().map(|x| x.price());
        return prices.sum()
    }

    fn add_item(&mut self, i: Box<dyn Item>) -> Result<(), &str>{
        self.items.push(i);
        return Ok(())
    }

    fn remove_item(&mut self, position: usize) -> Result<(), &str>{
        _ = self.items.remove(position);
        return Ok(())
    }
}

Since there's no inheritance in rust, I had to state the behavior in terms of traits, just exposing the behavior and not attributes like items for example. Therefore I decided to aggregate the composed structs with an ItemComposite in contrast to inheriting it as I would do in a OO language. When composed-related operations such as price are invoked by the client the composed class does part of the operation and delegates the children-related part to the Item composite.

pub struct Lens {
    composite: ItemComposite,
    pub(crate) price: f64,
}

impl Lens {
    pub fn new(price: f64) -> Self {
        return Lens{
            composite : ItemComposite::new(),
            price,
        }
    }
}


impl Item for Lens {
    fn price(&self) -> f64 {
        return &self.price + &self.composite.price()
    }

    fn add_item(&mut self, i: Box<dyn Item>) -> Result<(), &str>{
        return self.composite.add_item(i);
    }

    fn remove_item(&mut self, i: usize) -> Result<(), &str>{
        return self.composite.remove_item(i);
    }
}

pub struct Frame {
    composite: ItemComposite,
    price: f64,
}

impl Item for Frame {
    fn price(&self) -> f64 {
        return &self.price + &self.composite.price()
    }

    fn add_item(&mut self, i: Box<dyn Item>) -> Result<(), &str>{
        return self.composite.add_item(i);
    }

    fn remove_item(&mut self, i: usize) -> Result<(), &str>{
        return self.composite.remove_item(i)
    }
}

impl Frame {
    pub fn new(price: f64) -> Self {
        return Frame{
            composite : ItemComposite::new(),
            price,
        }
    }
}

pub struct Treatment {
    pub price: f64,
}

impl Item for Treatment {
    fn price(&self) -> f64 {
        return self.price
    }
}

impl Treatment {
    pub fn new(price: f64) -> Self {
        return Treatment{
            price,
        }
    }
}

pub struct Signature {
    pub price: f64,
}

impl Signature {
    pub fn new(price: f64) -> Self {
        return Signature{
            price,
        }
    }
}

impl Item for Signature {
    fn price(&self) -> f64 {
        return self.price
    }
}

Code tests

#[cfg(test)]
mod test {
    use crate::items::*;

    #[test]
    fn calling_add_item_from_an_not_composed_item() {
        let mut treatment = Treatment::new(200.0);
        let sig = Signature::new(100.0);

        let res = treatment.add_item(Box::new(sig));

        assert!(res.is_err())
    }

    #[test]
    fn assemblying_an_complte_glass_product() {
        let treatment = Treatment::new(200.0);
        let mut lens = Lens::new(300.0);
        let _ = lens.add_item(Box::new(treatment));

        let sig = Signature::new(100.0);
        let mut frame = Frame::new(500.0);
        let _ = frame.add_item(Box::new(lens));
        let _ = frame.add_item(Box::new(sig));

        assert_eq!(frame.price(), 1100.0);
    }
}

code link on my github:

https://github.com/igorcavalcante/design_patterns/blob/main/composite

Alternative rust approach

A third approach would be to create a trait that extends the item trait and adds children-related behavior. It would work but could add complexity to the API client since probably they would need to differentiate between a Leaf and a Composed struct.

Difficulties that I found:

Basically, all my problems were hot to adapt an OO pattern to rust. Such as

• No abstract classes with attributes

• Some trouble with borrowing and other kinds of compile checks

• Some optional aspect is to share behavior to manage the children's objects

Final thoughts

It would be easier to use a more Object Oriented language to do the same job, but It could be done using Rust with good effectiveness too. As a rust learner, I had some trouble trying to figure out how to borrow variables, use traits, and use modules as anyone should have. Certainly, I will use this pattern in a case of hierarchy-organized structures

Sources

Design patterns

Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Composite in Rust

https://refactoring.guru/design-patterns/composite/rust/example

The "Composite Pattern" in Rust

AXEL FORTUN https://grapeprogrammer.com/composite-pattern-rust/