# SailSafe.1: Revisiting rotten code

They say we're all "[_Writing Tomorrow's Legacy Code Today_](http://ronjeffries.com/articles/017-02ff/ipad-e-legacy/)". I've long found this to ring true in my academic, professional, and side projects. No truer in fact, than when I recently revisited the first object-oriented project I produced during my first year of university... oh boy. I felt that since graduating, the time had come to revisit these beginnings to tidy up and complete the original (missed) vision.

--- 

Allow me to be frank - my aim is not to make this legacy codebase perfect, production-ready, or even best-practice. However, my intention is simply to improve the structure of this application as its design (or lack thereof) and implementation frustrated me. Simply put, it just needed to be _better_ than it was; coherent, at least.

Whilst I was learning new concepts and new ways to think, this lack of experience led to poor object-oriented structure, separation of concerns,  and data representation and management, despite the simplicity of the '_[BREAD](http://paul-m-jones.com/archives/291)'  (Browse, Read, Edit, Add, Delete)_ operational requirements. I wanted to implement the vision I originally had but struggled to implement at the time (time constraints and personal reasons), not some perfect version of it. I felt it unfinished business if not done how I wished, originally, and more valuable to highlight the faults with that vision as I went.

## Reviewing the Specification
The specification behind this application was as follows:

> _Produce an offline desktop application for the creation and management of ferry bookings for vehicles. The company operates 4 sailings per day; 2 during the am and 2 in the pm. The sailings within each pair should alternate in direction. For example, one early sailing travels north to south and the other vice versa._ 
> 
> _Required features:_ 
> 
> - _User authentication_
> - _Create a booking_
> - _View a booking_
> - _Edit a booking_
> - _Delete a booking_
> - _Search for a booking by customer or vehicle information_
> 
> _Notes:_ 
> 
> - _A booking should collect general information about the customer, their vehicle, and their preferences for the sailing._ 
> - _Each sailing is restricted to 3 vehicle lanes, with limited sizes. As these fill to capacity, other lanes should be used. The bookings should indicate in which lane on the sailing the vehicle will be located._ 
> - _The persistence method should be a CSV file._

### Devising a Plan
The first stage to refactoring this mess, I felt, was to create a suitable object structure that reflected the real-world hierarchy of the concepts at play. For example, by reading the specification we note these concepts; _Booking_, _Sailing_, _Lane_, _Vehicle_, _Customer_, and so on.  Structuring these relationships during the desired functional processes was essential to improving the maintainability and extensibility of this software as previously, the views (WinForms) were performing all this internally (and more...).

After this, it was important that these new domain models which now properly represent data were separated from functional processes to have a consumer-based relationship. Similarly, access and management of the data these models represented needed separating into dedicated and constrained processes. I decided to use the well-known ORM Repository pattern via interfaces for abstract contracts for which multiple clients may implement common actions with specialist concretions. For example, although a _UserAccount_ and a _Booking_ both require saving, the method by which this is achieved, or the data involved, might vary. But the contract to provide the ability to save these abstract concepts is common between them.

### In Summary
You can view all this tinkering on a dedicated branch on [GitHub](https://github.com/cognophile/sailsafe/tree/1-enhance-refactorClassDesign). This branch is focused on addressing these aspects of the improvements - class structure and data access and management strategies.