When we think about writing code, we always want to ensure our code is readable. While this sounds counterintuitive, code is read many more times than it's written. One core tool in a developer's toolbox to ensure maintainable code is the **function**.
@ -25,7 +25,8 @@ Just as important is the ability to name a function. While this might seem trivi
The syntax for a function looks like the following:
```javascript
function nameOfFunction() { // function definition
function nameOfFunction() {
// function definition
// function definition/body
}
```
@ -34,7 +35,7 @@ If I wanted to create a function to display a greeting, it might look like this:
```javascript
function displayGreeting() {
console.log('Hello, world!');
console.log("Hello, world!");
}
```
@ -62,9 +63,7 @@ To make a function more reusable you'll often want to pass information into it.
Parameters are listed in the definition part within parenthesis and are comma separated like so:
```javascript
function name(param, param2, param3) {
}
function name(param, param2, param3) {}
```
We can update our `displayGreeting` to accept a name and have that displayed.
@ -79,7 +78,7 @@ function displayGreeting(name) {
When we want to call our function and pass in the parameter, we specify it in the parenthesis.
```javascript
displayGreeting('Christopher');
displayGreeting("Christopher");
// displays "Hello, Christopher!" when run
```
@ -88,7 +87,7 @@ displayGreeting('Christopher');
We can make our function even more flexible by adding more parameters. But what if we don't want to require every value be specified? Keeping with our greeting example, we could leave name as required (we need to know who we're greeting), but we want to allow the greeting itself to be customized as desired. If someone doesn't want to customize it, we provide a default value instead. To provide a default value to a parameter, we set it much in the same way we set a value for a variable - `parameterName = 'defaultValue'`. To see a full example:
```javascript
function displayGreeting(name, salutation='Hello') {
function displayGreeting(name, salutation = "Hello") {
console.log(`${salutation}, ${name}`);
}
```
@ -96,10 +95,10 @@ function displayGreeting(name, salutation='Hello') {
When we call the function, we can then decide if we want to set a value for `salutation`.
```javascript
displayGreeting('Christopher');
displayGreeting("Christopher");
// displays "Hello, Christopher"
displayGreeting('Christopher', 'Hi');
displayGreeting("Christopher", "Hi");
// displays "Hi, Christopher"
```
@ -127,7 +126,7 @@ function createGreetingMessage(name) {
When calling this function we'll store the value in a variable. This is much the same way we'd set a variable to a static value (like `const name = 'Christopher'`).
> [](https://www.youtube.com/watch?v=1TvxJKBzhyQ)
### Introduction
@ -28,10 +25,11 @@ On your computer, create a folder called 'terrarium' and inside it, a file calle
Or
Use these commands on your git bash:
* `mkdir terrarium`
* `cd terrarium`
* `touch index.html`
* `code index.html` or `nano index.html`
- `mkdir terrarium`
- `cd terrarium`
- `touch index.html`
- `code index.html` or `nano index.html`
> index.html files indicate to a browser that it is the default file in a folder; URLs such as `https://anysite.com/test` might be built using a folder structure including a folder called `test` with `index.html` inside it; `index.html` doesn't have to show in a URL.
@ -223,15 +221,12 @@ There are some wild 'older' tags in HTML that are still fun to play with, though
HTML is the 'tried and true' building block system that has helped build the web into what it is today. Learn a little about its history by studying some old and new tags. Can you figure out why some tags were deprecated and some added? What tags might be introduced in the future?
Learn more about building sites for the web and mobile devices at [Microsoft Learn](https://docs.microsoft.com/learn/modules/build-simple-website/?WT.mc_id=academic-77807-sagibbon).
## Assignment
[Practice your HTML: Build a blog mockup](assignment.md)
CSS, or Cascading Style Sheets, solve an important problem of web development: how to make your web site look nice. Styling your apps makes them more usable and nicer-looking; you can also use CSS to create Responsive Web Design (RWD) - allowing your apps to look good no matter what screen size they are displayed on. CSS is not only about making your app look nice; its spec includes animations and transforms that can enable sophisticated interactions for your apps. The CSS Working Group helps maintain current CSS specifications; you can follow their work at [World Wide Web Consortium's site](https://www.w3.org/Style/CSS/members).
@ -21,7 +20,6 @@ You should have the HTML for your terrarium built and ready to be styled.
> Check out video
>
> [](https://www.youtube.com/watch?v=6yIdOIV9p1I)
### Task
@ -259,8 +257,6 @@ To complete the post-lecture quiz, go through this Learn module: [Style your HTM
CSS seems deceptively straightforward, but there are many challenges when trying to style an app perfectly for all browsers and all screen sizes. CSS-Grid and Flexbox are tools that have been developed to make the job a little more structured and more reliable. Learn about these tools by playing [Flexbox Froggy](https://flexboxfroggy.com/) and [Grid Garden](https://codepip.com/games/grid-garden/).
### Inheritance and Composition in game development
In earlier lessons, there was not much need to worry about the design architecture of the apps you built, as the projects were very small in scope. However, when your applications grow in size and scope, architectural decisions become a larger concern. There are two major approaches to creating larger applications in JavaScript: *composition* or *inheritance*. There are pros and cons to both but let's explain them from within the context of a game.
In earlier lessons, there was not much need to worry about the design architecture of the apps you built, as the projects were very small in scope. However, when your applications grow in size and scope, architectural decisions become a larger concern. There are two major approaches to creating larger applications in JavaScript: _composition_ or _inheritance_. There are pros and cons to both but let's explain them from within the context of a game.
✅ One of the most famous programming books ever written has to do with [design patterns](https://en.wikipedia.org/wiki/Design_Patterns).
@ -34,7 +32,6 @@ The idea is to use `classes` in conjunction with `inheritance` to accomplish add
Expressed via code, a game object can typically look like this:
```javascript
//set up the class GameObject
class GameObject {
constructor(x, y, type) {
@ -46,11 +43,11 @@ class GameObject {
//this class will extend the GameObject's inherent class properties
class Movable extends GameObject {
constructor(x,y, type) {
super(x,y, type)
constructor(x,y, type) {
super(x,y, type);
}
//this movable object can be moved on the screen
//this movable object can be moved on the screen
moveTo(x, y) {
this.x = x;
this.y = y;
@ -59,21 +56,21 @@ class Movable extends GameObject {
//this is a specific class that extends the Movable class, so it can take advantage of all the properties that it inherits
class Hero extends Movable {
constructor(x,y) {
super(x,y, 'Hero')
constructor(x,y) {
super(x, y, "Hero");
}
}
//this class, on the other hand, only inherits the GameObject properties
class Tree extends GameObject {
constructor(x,y) {
super(x,y, 'Tree')
constructor(x,y) {
super(x, y, "Tree");
}
}
//a hero can move...
const hero = new Hero();
hero.moveTo(5,5);
hero.moveTo(5,5);
//but a tree cannot
const tree = new Tree();
@ -83,7 +80,7 @@ const tree = new Tree();
**Composition**
A different way of handling object inheritance is by using *Composition*. Then, objects express their behavior like this:
A different way of handling object inheritance is by using _Composition_. Then, objects express their behavior like this:
```javascript
//create a constant gameObject
@ -143,8 +140,8 @@ Another pattern common in game development addresses the problem of handling the
This pattern addresses the idea that the disparate parts of your application shouldn't know about one another. Why is that? It makes it a lot easier to see what's going on in general if various parts are separated. It also makes it easier to suddenly change behavior if you need to. How do we accomplish this? We do this by establishing some concepts:
- **message**: A message is usually a text string accompanied by an optional payload (a piece of data that clarifies what the message is about). A typical message in a game can be `KEY_PRESSED_ENTER`.
- **publisher**: This element *publishes* a message and sends it out to all subscribers.
- **subscriber**: This element *listens* to specific messages and carries out some task as the result of receiving this message, such as firing a laser.
- **publisher**: This element _publishes_ a message and sends it out to all subscribers.
- **subscriber**: This element _listens_ to specific messages and carries out some task as the result of receiving this message, such as firing a laser.
The implementation is quite small in size but it's a very powerful pattern. Here's how it can be implemented:
@ -154,21 +151,20 @@ class EventEmitter {
constructor() {
this.listeners = {};
}
//when a message is received, let the listener to handle its payload
//when a message is received, let the listener to handle its payload
on(message, listener) {
if (!this.listeners[message]) {
this.listeners[message] = [];
}
this.listeners[message].push(listener);
}
//when a message is sent, send it to a listener with some payload
//when a message is sent, send it to a listener with some payload
Learn more about Pub/Sub by [reading about it](https://docs.microsoft.com/azure/architecture/patterns/publisher-subscriber/?WT.mc_id=academic-77807-sagibbon).