Object’s life cycle

Let’s look at the life cycles of Sample objects. An object’s life cycle starts with object creation, then state changes, and (in some cases) the end of its processing life when there are no more references to it. We have three scenarios:

Initial load

We’ll need a load() method to populate a TrainingData object from some source of raw data. We can imagine a load() method using a CSV reader to create Sample objects with a species value, making them KnownSample objects. The load() method splits the KnownSample objects into the training and testing lists, which is an important state change for a TrainingData object.

Hyperparameter testing

We’ll need a test() method in the Hyperparameter class. The body of the test() method works with the test samples in the associated TrainingData object. For each sample, it applies the classifier and counts the matches between botanist-assigned species and the best guess of our AI algorithm. This points out the need for a classify() method for a single sample that’s used by the test() method for a batch of samples. The test() method will update the state of the Hyperparameter object by setting the quality score.

User-initiated classification

A RESTful web application is often decomposed into separate view functions to handle requests. When handling a request to classify an unknown sample, the view() function will have a Hyperparameter object used for classification; the Botanist will choose this to produce the best results. The user input will be an UnknownSample instance. The view() function applies the Hyperparameter.classify() method to create a response to the user with the species the iris has been classed as. Does the state change that happens when the AI classifies an UnknownSample really matter? Here are two views:

  • Each UnknownSample can have a classified attribute. Setting this is a change in the state of the Sample. It’s not clear that there’s any behavior change associated with this state change.

  • The classification result is not part of the Sample at all. It’s a local variable in the view function. This state change in the function is used to respond to the user but has no life within the Sample object.

There’s a key concept underlying this detailed decomposition of these alternatives:

There's no "right" answer.

Explication for updated UML

Some design decisions are based on non-functional and non-technical considerations. These might include the longevity of the application, future use cases, additional users who might be enticed, current schedules and budgets, pedagogical value, technical risk, the creation of intellectual property, and how cool the demo will look in a conference call.

It’s better to start with something of a manageable level of complexity and then refine and expand it until it does everything they need." Because of that, we’ll consider a change in state from UnknownSample to ClassifiedSample to be very important. The Sample objects will live in a database for additional marketing campaigns or possibly reclassification when new products are available and the training data changes. We’ll decide to keep the classification and the species data in the UnknownSample class.

This analysis suggests we can coalesce all the various Sample details into the following design:

Get hands-on with 1400+ tech skills courses.