CSC/ECE 517 Spring 2023 - E2337. Reimplement node hierarchy

Introduction

Packages of information are distributed based on the context that they are delivered. For courses, information and functionalities are packaged into Course nodes and team information is packaged into Team nodes. These nodes are supplemented by the base node class in order to inherit basic functionality/attributes such as the type of node, the parent id, identifying whether the node is a leaf or not, etc. This hierarchical structure allows for code reuse and custom implementations to exist alongside default implementations in order to keep functionalities modular and isolated, minimizing the risk of breakage.

Problem Statement

First off, the node models have a problem with repetition in two major areas. First off, Node.rb defines a bunch of functions to fetch a given property such as name, directory, creation_date, etc. These functions all fetch data from the same entity with the same filter parameters. Instead of having five functions, we can consolidate down to one function where a given parameter would be passed in. This parameter could specify which field we want to fetch on a given entity. For example, we could fetch the creation date of an entity by invoking a call like such: node.getProperty("creation_date"). The getProperty function would be responsible for parsing the parameter and determine which field needs to be returned back to the user.

Secondly, there are methods that are repetitive between assignment_node.rb and course_node.rb. In order to reduce repetition, the shared methods can be pulled out into a module, which then the two node models would import in order to use the methods. Some of these repetitive methods are get_instructor_id, retrieve_institution_id, get_private, etc.

Class Hierarchy