It's very good for you to go through those because the more practice you have with them the more familiar they're going to be and then it's going to be pretty much second nature when you're building these out yourself.

Now, this combines many of the different components that we've learned throughout this entire course. You may notice some things such as multiplicity here and there are also some very unique forms of it that we haven't really integrated before such as right here. We have a one to many type relationship but this is an interesting one usually our one to many things are usually one two and then an asterisk but right here I'm doing one to zero dot dot.

And what that means is that a form can exist with out a set of customers. And the reason for that is a pretty straightforward one. If you remember back to our process a marketing rep can create a form. So as soon as they've created that form it is LIVE. It's on the site but no one's actually filled it out yet. So in that particular state there is a form. So we have one but it does not have any customers that are related to that. So whenever you're writing your multiplicities make sure that you're building those in a way that they just follow common sense kinds of patterns. And so it's a very common way of doing it.

I also wanted to show a little bit different way of denoting it compared with how we've done in this course so far. Many times we'll just do one two and asterisks but I like to, in cases like this where there is a potential that there could be zero of an item, I like to be explicit with that there are many times where it's going to be one to one dot dot asterisks. And what that would represent is that whatever that relationship is and as it exists it needs to at least have one. So this would be a situation where say a marketing rep created a form but it wasn't actually a full valid form until there was a customer associated with that so they'd have to add a customer to the form. And in this example, that really doesn't make sense but there are plenty of times where you do need to be able to have a one to one or more type of relationship so that that's one very important part of the solution. I want you to review and focus on.

The next is really in how inheritance can work inside of these class diagrams coming down to message,

we have our message class right here. And this is our wrapper for our entire communication system. This is going to have a customer id the assigned representative. All of those different attributes and a message though may be many different things. A message might be an e-mail, an SMS message, or some other external channel such as slack or Hip chat or Facebook or Twitter or any other connector that you need.

Now the reason why I like this type of implementation is because a message is a parent class and then an email is a type of message, SMS is a type of message. One of these external channels. Is a type of a message. My rule of thumb whenever I'm deciding if I want to implement inheritance inside of some type of application is if I can describe it and I can put the class names in a sentence like that where it can where one class is a type of another class that is one of the most traditional and pure forms of a time where you want to use inheritance an email by definition is a type of a message each one of these are. And so this is a case where utilizing an inheritance or some form of it definitely makes sense.

The last element that I want to mention is a reference to our customer class here.

Now in many different applications usually a customer would be connected to user but in applications where the customer is not actually a user. So in other words they do not have a username and password they're not logging into the system or any of those tasks all the tasks that a marketing rep needs then the customer is just a standalone class. This is someone who signs up on one of the forms and we need a way of tracking them. So we obviously need some type of database record for that customer but they're not going to be a user. And that's a very important distinction because if you built this and said OK we have a user abstract class and then customer inherits from it and so does marketing rap.

That would be a poor way of structuring your system because a customer is not a type of user. If you explain what a user does a user is someone who logs in the system with the username and password which you can see all of those different elements right here.

A customer does none of those things, and so because of that a customer would not be a good fit for inheriting from user. A marketing rep, on the other hand would be. And if you're wondering why I created two different classes we have a marketing rep and a user.

There is a very important reason why. And I like to structure my systems like this is because 9 times out of 10 when I build a system even if the stakeholders say there's never going to be any other type of user except for a marketing rep 9 times out of 10 that's not accurate. At some point someone's going to say you know what we need an admin or we may eventually want the customers to be able to log in and there can be all kinds of different users. That happens constantly and because of that just based off of years and years of experience I now always separate my user types out so that I can prepare for when that happens. So yes marketing rep technically is a user and that's a reason why we have, noticed in the multiplicity we have this one to one relationship.

That means that every user is only going to have one marketing rep and vice versa.

The reason for that is because at some point there is most likely going to be some type of site admin or some other type of user that needs to be created and instead of just log jamming the entire set of requirements and behavior for that other type of user inside of the User class I can simply have it inherit from user and then have a clean interface for that other type.