Review Splittng Features Across Mutliple Objects

[supermanzer]

One of the beauties of Object Oriented Programming is multiple inheritance. Considering the number of methods and properties in the DataBuoy class, it may make maintenance and code review easier to follow. This was inspired by the time I've spent looking through the Django and Django-REST-Framework source code.

Pro

• Simplify DataBuoy class definition
• Separate functions by area of concern (e.g. URL constructions & requests, data structures and processing, etc.)

Con

• Spreads process flow across multiple object definitions
• Despite being declared separately, because the functionality is inherited we have the same risk of side effects

Will review and either suggest splitting up functionality into multiple classes or not

[supermanzer]

Update

Additional Pro

• Breaking DataBuoy into multiple classes could provide more basic objects and allow for easier extension by researchers who wish to create their own classes that inherit the functionality specific to an area of concern

Decision

Breaking up DataBuoy class is a Go.

First draft would be to split DataBuoy functionality into two more generalized classes that handle

• Managing URL formation and validation + fetching data
• Ingesting data, performing QA processes and splitting, storing data & saving to disk

Functionality that is inherently specific to NDBC data stations will remain in the DataBuoy class. In all three classes I will endeavor to replicate the static variable/getter function approach used throughout classes like Django Class Based Views to allow researchers to easily extend these classes for more customized functionality.