-: (instructor)So before we continue
any further in our project,
we should now think a little bit
about our project Architecture.
Now, there are some quite advanced
architecture patterns in JavaScript.
And we will actually talk a little bit about this
by the end of the course.
But in this small project,
we will simply use object oriented programming with classes,
just like we learned in the last section.
And so this way,
you can then use these concepts here in a real project.
And remember that Architecture is all about
giving the project a structure.
And so in that structure,
we can then develop the functionality.
And so in this project,
I decided that the main structure
will come from classes and objects.
All right, so let's now dig a little bit deeper
into this Architecture that we gonna use.
So to start, one of the most important aspects
of any Architecture,
is to decide where and how to store the data.
Because data is probably
the most fundamental part of any application.
Because without data, it doesn't even make sense
to have an application in the first place.
Right, what would the application be about,
if not about some sort of data.
Now, in this case, the data that we need to store
and to manage comes directly from the user stories.
So right in the first user story,
we can already see that we will somehow
need to store the location, distance,
time, pace, and steps per minute.
And to fit the second user story,
we will have to implement basically the same data.
So again, location, distance, time and speed
but then also the elevation gain
instead of the steps per minute.
And so we will design our classes,
so that they can create objects
that will hold this kind of data.
And I believe that this is the best way
of designing the classes to really fit all user stories.
So you see that we are gonna have a big parent class,
which will be called Workout.
And so this one is gonna hold
the distance duration in coordinates.
And then we will have a more specific class for the running,
which will hold the cadence and the pace.
All right, and the reason why the classes
are designed like this is
because the distance duration
and coordinates are common
to both of the types of activities.
So both to Running and to Cycling
and so therefore they are in the Parent Class.
All right, and the same will also be true for some methods.
And so we will see that once we implement it.
And then for each type of activities,
as you see, we have one child class,
so that each child class can hold the data
and methods that are specific to that type of activity.
So I hope that makes sense
and this is the whole reason
why inheritance basically actually exists.
So that we can have more specific classes
that can inherited behavior
and common properties that are
common to all the child classes.
So the cadence and pace are specific for Running
and then the elevation gain and speed
are specific to the Cycling.
Okay, but once again, the Cycling also has
distance, duration, and coordinates.
And so that's why they are there in the parent class,
so in the workout class,
then here in this diagram,
you also see that we have some other properties,
like the ID and date.
But we will see why,
once we start implementing the code.
And yeah, that's actually it for the data.
So this kind of diagram is something
that you will commonly see
when working in object oriented programming.
So usually each class is represented by a box like this,
where in the top part,
you're gonna have the properties
and in the bottom part, the methods.
And of course, each class here
will have more than just the constructor method.
And so that's why I have these three dots there.
All right, so for now,
that's all we need to know
about the architecture of our data.
But now about the rest of the Architecture,
it's gonna be more about structuring the code
that we already have from the previous lectures.
And the events that we already have
are the loading of the page,
then receiving a position from the Geolocation API.
So this one isn't an event in the traditional sense.
So we're not handling it with Add Event Listener,
but we can still classify it as an event.
Then we have to click on the map.
We have changing the input from Cycling to Running,
or from Running to Cycling, remember,
and then we also have the event of submitting a form.
And so all we have to do now
is to create different functions
that will handle these different events.
And in fact, what we are gonna do
is to create a big class called App
that will basically hold all of these functions as methods.
So from a quick look at this application class diagram,
we can immediately see that loading the page
will of course trigger the constructor of the object
that we're gonna create through this class.
Okay, and so then right at the beginning,
we want to get the current position
of the user using the Geolocation API.
And so that's why there is that arrow
pointing from constructor to Get Position.
Then as we receive that position,
we want to load the map based on that position.
And so therefore, we're gonna have a method called Load Map.
Then as we click on the map,
we want a method called Show Form.
Then as we change the input,
we want a method called Toggle Elevation Field.
And then, and probably the most important one
is the event of submitting the form.
And this new workout method
will basically be the heart of this entire class,
because this is the one that will create new Running objects
or new Cycling objects.
And of course, these objects will be built based on the data
that's coming in from the form.
And as the user keeps adding Running, or Cycling workouts,
a new object will be created for each of the workouts.
And each of them will then be stored in a Workouts Array,
which will basically hold all of these objects.
Alright, so this is gonna be an important class property
that all methods of the class
will then be able to use to work with the workouts.
And so with this structure here,
we have everything that is related
to building the application itself,
organized into one neat block of data
and functionality.
And actually, having a class
that contains all the data
and methods about the application,
like we have here is a pretty common thing that you will see
in simple JavaScript applications like this one.
Now, if the application was a bit more complex,
then we could divide this Architecture even further
and create one class
that would only be concerned with the user interface
and one class for the so called Business Logic.
So basically, the logic
that works only with the underlying data.
But in this case, we can just keep it simple like this.
And so as I mentioned before,
this Architecture will then allow us to have everything
that is about the application in one nice,
self contained block.
And besides the application itself,
we then also have these classes
that are only concerned about the data.
And so therefore, application and data
will be nicely separated in a very logical way, I believe.
Now, What's also great about this
is that we will be able to protect all of these methods,
so that they are nicely encapsulated
and not accessible from everywhere else in the code.
So that's the reason why you see these
underscores on all of the method names.
Right, so that is, again, the convention
that we can use to protect method names
from being changed and used from the outside.
And so this will make the code a lot easier to work with
because we will know for sure
that no place else in the code is working with the data.
And yeah, calling any of the methods here.
And trust me with experience,
you will really start to appreciate these kinds of things.
Now right, but anyway,
this is the initial approach for Architecture
that we're now gonna implement.
And of course, based on the code
that we already have.
We will keep adding more methods
and properties as we go
but this is already an excellent starting point.
So maybe take another minute or two,
to study this diagram.
And then in the next video,
we will refactor our code to fit this Architecture.