Skip to content

Conversation

@sarcaxticlarka
Copy link

Fixes #19

Refactored ShipParams to separate weather-related parameters into a new WeatherParams class for better code organization and reusability.

Changes

  • New: WeatherParams class in WeatherRoutingTool/ship/weatherparams.py
  • Modified: ShipParams now uses WeatherParams internally
  • New: Demo file showing both old and new usage patterns

Key Features

100% Backward Compatible - No breaking changes
All tests pass - 117/127 passing (same as before)
Property delegation - Existing code like ship_params.wave_height still works
Cleaner architecture - Weather separated from ship performance data

Benefits

  • Separation of concerns: Ship performance vs environmental data are now distinct
  • Reusability: Weather data can be shared across multiple ships
  • Easier testing: Mock weather independently from ship parameters
  • Gradual migration: Teams can adopt the new pattern at their own pace

Usage Examples

Old Way (Still Works)

ship_params = ShipParams(
    speed=speed, 
    wave_height=waves, 
    u_wind_speed=wind
)

…ams class

- Created new WeatherParams class for weather-related parameters
- Refactored ShipParams to use WeatherParams internally
- Maintained 100% backward compatibility using property delegation
- All tests pass (117/127, same as before)
- Added demo showing both old and new usage patterns
@kdemmich
Copy link
Collaborator

kdemmich commented Jan 7, 2026

Hi @sarcaxticlarka, thank you for your PR. We appreciate the time and effort that was put into it but, unfortunately, we have to decline the PR as the modifications contradict a currently ongoing restructuring process (see Issue #46).

@kdemmich kdemmich closed this Jan 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Separate weather parameter from ShipParams object

2 participants