Object Modeling as Nouns

[00:00:00]
>> If you've never ever programmed before, and you just randomly took a wrong turn on the highway, and you got lost on the bad part of town and you ended up in this workshop. It's cool because, this would be the place to show up because we're going to approach programming from the standpoint that we were assuming nothing.

[00:00:27]
And the one thing that I do wanna call out is we're gonna do a little bit wax on, wax off. And if you seen the movie and somebody else has it and I don't understand what he's talking about fill it in and chats, but essentially Mr. Miyagi had Denilson do a bunch of really tedious stuff that didn't make sense.

[00:00:50]
And then, at some point, Daniel said, I've had enough I'm not doing this. And speaking of wax in the car, Mr. Miyagi is like, well, you've been actually learning karate the entire time, try to punch me. Dennison tried to punch him and all of a sudden, or actually Mr. Merrick said, I'm gonna punch you wax the car and Dennison he basically blocked the punch.

[00:01:08]
So what we're gonna do now is we're going to wax the car and we are going to then realize that we're actually blocking punches. So even as small children, we understand that our world consists of things and that these things have characteristics that make them unique. And so we understand that we have a car.

[00:01:42]
That might be read, it might be a Ford or Chevy or a Tesla. That you have a person that has a name, first name and a last name. Hair color. We understand that there are things in this world that have characteristics and our job is to articulate those characteristics, and the relationships that those objects have with each other.

[00:02:17]
Now, I would imagine that at some point, at some time, somebody is gonna see this and they're gonna do this huge I roll like seriously we're talking about like objects like primitive objects. The problem is that the majority or a major portion of complexity stems from the fact that someone has not taken the time to properly model the domain that they are in.

[00:02:50]
And so, when you wanna talk about application complexity, you have to start at the domain model, like this is the most important thing in the world. When you're writing code is you have to get your domain model correct. What that means is you have to create and define the objects that are going to exist in your application in a way that is accurate for the reality in which you're trying to describe.

[00:03:19]
Let me give you an example. I was working with someone the other day and apprentice and their physical therapist and we were modelling the domain of a physical therapist. And what we realized or what he realized is that you would model a patient and you would model a physical therapist.

[00:03:42]
And naively, you would say that a physical therapist has a relationship with a patient, a direct relationship, but what we realized is that the relationship between the patient and the therapist was only through the treatment. And you realize that you actually have a one or many to many relationship is that one patient can actually have more than one therapist and one therapist can have more than one patient.

[00:04:16]
And all sudden now you realize that the relationship between the therapist and the patient is that if you were to model it is not direct. But there's actually a treatment or a session that exists in between that and if he had gotten that wrong, it would have completely impeded and impaired his ability to model an application around that.

[00:04:37]
And so it's incredibly important to get data models correct which come down to yeah, like, we are going to write very simple objects to describe a domain. The one thing I will say is that when you understand a domain, or a domain object, the domain model, there's a lot of things that you can know about that application.

[00:05:07]
So if I showed you this client object. And I asked you, what do you think an input form, like a form would look like, to create a new client? Everybody is hopefully looking and they're saying, well, that's a form with three fields first name, last name, company. It's easy, like, if I gave you a user object, you know what that form looks like.

[00:05:32]
Not only that is you know what the rest endpoints look like. You know what your Redux is gonna look like, you know what your NTRs is going to look like. There's so much that you can know about an application. When you understand the domain model, so back to our objects in JavaScript, you can define an object is an object literal.

[00:05:57]
Like this is I'm saying with my curly braces. I have this thing And I have these properties or characteristics that have these values. First name is John. Last name is Doe company is Acme, Inc. And you can have various properties on this. So in this case, if I'm working with a field I generally will have a blank or like a mock object where I can say the ID is null, first name, last name, company is empty.

[00:06:27]
And so you can have more than one object with different properties. Not only that, but you can have a collection of objects. And so you can have more than one object in a collection. So We'll talk about objects which are nothing more than nouns or data structures. And then you're going to have an array or a collection of more than one of those objects.

[00:06:52]
Now we have an object and then we have interfaces. In an interface is a way for us to describe what something is. And so in a way, I think of an interface as a contract, that if I'm going to create, a bunch of clients, and I'm going to ensure that these are indeed clients as advertised.

[00:07:31]
By defining an interface and implementing that interface, I now have the ability to strongly typed that object as well as strongly type the collection. And so a contract or an interface is a way to communicate intent and to ensure compliance across your application. Now, we have classes. So if an object is an instance of something and an interface is a contract, a class is nothing more than a blueprint to create objects.

[00:08:19]
And so if you have, for instance, a housing development, which we have a ton of these in Phoenix that you might say we're building this housing development and here's the blueprint. Or here's three blueprints for the three possible houses that we can have. So the blueprints are not a house.

[00:08:40]
A class is not an instance of an object. A blueprint only defines the behavior and the parameters that are going to exist for that object when it's created. And then a, I think of interfaces is, let's say like city regulations or zoning laws that if you're going to build a house in this neighborhood then it can't be more than two storeys high.

[00:09:07]
Because imagine how funny that would look, if you had a six storey house in a neighborhood of, a bunch of single story ranch houses, that would be hilarious. And so all a class does is it's a blueprint. For defining how an object is going to be created and the properties and the behavior that you're going to give it.

[00:09:36]
And so now I've defined a VIP client and I'm saying. Iron Man equals new VIP client which then returns an instance of that object and then we can trace this out.