freeCodeCamp / CurriculumExpansion

Creative Commons Attribution Share Alike 4.0 International
314 stars 105 forks source link

Object Oriented Programming Challenges #15

Closed QuincyLarson closed 8 years ago

QuincyLarson commented 8 years ago

@utsab is in charge of coordinating the expansion of these challenges, but he needs your help.

For each challenge, please reply to this GitHub issue with:

  1. Challenge description text
  2. Test suite (using the assert method)
  3. The seed code, which is pre-populated in the editor at the beginning of the challenge
  4. A working solution that makes all tests pass

Here are the challenges we have currently planned (these can be further expanded):

Objects

Constructors

Prototypes

Inheritance

Other

Here are the challenges as we originally discussed for archival purposes:

  • Declare JavaScript objects as variables #old
  • Constructors
    • Construct JavaScript objects with functions #old
    • Make instances of objects with constructor functions #old
    • Use instanceof to show the type of an object created with a constructor
    • constructor property of an instance also shows the type of an object
    • Make unique objects by passing in parameters to constructor #old
  • More on this
    • Every function gets a variable this ==> context in which the function was called. Illustrate with exercise.
    • this can refer to the global context. Illustrate with exercise
    • this can refer to a specific object. Illustrate with exercise
    • Explicitly set "this" with the "call", "apply", "bind" methods
    • use strict
  • Prototypes
    • Convert constructor-defined methods, "setGear" and "getGear" to prototype methods. (Explain that two "Bike" instances have the exact same method "setGear" ==> duplicate code ==> prototypes can help eliminate the duplicate code.)
    • Properties defined on prototype are available to all instances. Illustrate with exercise.
    • prototype properties vs. "own" properties
    • Iterate over all properties of an object
    • Iterate over all "own" properties of an object (using hasOwnProperty)
    • Iterate over all prototype properties of an object
    • Is the "constructor" property an "own" property or prototype property? Find out.
    • If instance sets its "own" property, it overrides the prototype's property
  • Prototypes with Constructors
    • Every object has a prototype property, including functions. A constructor function has its own prototype property. Illustrate with exercise.
    • When you create an object using new, the constructor's prototype property is assigned to the object instance's prototype. Exercise ==> print out the instance's "prototype" property
    • Changing a prototype affects all instances
    • Modify a built-in object's prototype, like Array. (Explain why this is not a good idea in production).
    • The constructor's prototype property is created with a "constructor" property equal to the function.
  • Inheritance
    • Objects inherit behavior from other objects via prototype chaining. A prototype chain occurs when one object's prototype is set to another object. Since the prototype itself is an object, it has its own prototype.
    • Objects automatically inherit from Object
    • Introduce concepts subtype and supertype
    • Use instanceof to show that an object is an instance of subtype and supertype
    • Show example where the subtype sets its prototype equal to an instance of the supertype
    • Show that you have to manually set the constructor property to the subtype
    • Calling supertype methods ===> use [SuperTypeName].call and pass in this
    • The obj.prototype is not obj's prototype.
  • Encapsulation (Data hiding)
    • Module pattern for creating private members ===> Immediately invoked function expression (IIFE)
    • Closure
    • Modules are great for single objects. Similar pattern for constructed objects. Reuse "Make object properties private" to show how to make private members within a constructor. #old
    • The underscore before name convention
  • Other
    • Prototypal chaining is not the only way to inherit behavior. ===> mixins
    • Various exercises to manipulate Arrays and Strings #old
HKuz commented 8 years ago

Hello @QuincyLarson @utsab and everyone else on this chain - I'm currently working on this section in the QA process and have a couple questions. Right now, these challenges are ordered to come after the ES6 section (see #46) and we've been converting the other new JS sections so their examples/seed code use ES6 syntax. (This is done for Regex and Debugging so far). Is this section replacing the current FCC Object Oriented section, or will it be layered with it? If it's replacing that section, should we convert this into ES6 syntax to be consistent? Given the new class syntax, does this materially change any of the challenges?

If we are converting to ES6 - I'm relatively new to using it, and would appreciate help to make sure the conversion is done correctly.

Let me know, thanks!

(Side note @QuincyLarson - this comment would also apply to the Functional Programming and the Advanced Data Structures sections as well)

QuincyLarson commented 8 years ago

@HKuz we plan to completely eliminate the old OOP/FP section.

Another note on this: what we are teaching is not technically ES6 - it is ES2016, which is two generations ahead of ES6.

Me and @BerkeleyTrue's thinking is we should just merge the ES6 section into the JavaScript section and call it "JavaScript". Then we can use the latest syntax in all of our challenges.

I will do this once we finish the ES6 section. It shouldn't affect your QA process.

HKuz commented 8 years ago

@QuincyLarson okay, thanks for clarifying. Makes sense to combine all the JS challenges together. I'll keep plugging on the QA process.

QuincyLarson commented 8 years ago

@HKuz great - it's a plan 🙂 We can assume that all JavaScript-related challenges on FCC can use ES2016 syntax, then.

utsab commented 8 years ago

@HKuz and @QuincyLarson, the original outline for the OOJS challenges does not factor in the ES6 "class" syntax. If we do emphasize the "class" syntax, then maybe we do not need the prototype-chain sections. With the new "class" syntax, we no longer need to use the prototype chain to implement inheritance.

QuincyLarson commented 8 years ago

@utsab my understanding is that the "class" syntax is just syntactic sugar. These objects still use prototypical inheritance. Perhaps @BerkeleyTrue or @alayek could chime in here.

If this is the case, we could introduce the class keyword after we finish covering prototypes, and explain how it makes things more convenient.

HKuz commented 8 years ago

@utsab et al - if you all do decide to add a new challenge, you can post it here and mention me. I'm almost through reviewing the others and adding a new one is not a problem. Just let me know where it would go in the order 😄 Thanks!

HKuz commented 8 years ago

Hi folks - here's a first cut of the introductory text for this section. This is meant to be a standalone intro, but the following section is Functional Programming. That's why I included the language about different approaches to software development - I'm thinking it'll help transition between the sections and tie them together.

Any comments or suggestions are welcome 😄

Introduction to the Object Oriented Programming Challenges

At its core, software development solves a problem or achieves a result with computation. The software development process first defines a problem, then presents a solution. Object oriented programming is one of several major approaches to the software development process.

As its name implies, object oriented programming organizes code into object definitions. These are sometimes called classes, and they group together data with related behavior. The data is an object's attributes, and the behavior (or functions) are methods.

The object structure makes it flexible within a program. For example, objects can exchange information with each other. One object would invoke a method and send data to the other in a process called message passing.

Object oriented programming uses the concept of inheritance. It allows a new class to inherit, or receive, all the features from a base or parent class plus a few of its own. Inheritance helps to avoid repeated code by reusing it between related classes.

Your choice of programming approach depends on a few factors. The type of problem, and how you want to structure your data and algorithms make a difference. This section covers object oriented programming principles in JavaScript.

QuincyLarson commented 8 years ago

@HKuz Excellent description. I would avoid using the word "invoke" here unless we've used it before this point. As with the other descriptions, I think this could ultimately be boiled down to just 2 or 3 paragraphs. It wouldn't be as comprehensive as this explanation is, but a lot more people would read the entire thing.

HKuz commented 8 years ago

@QuincyLarson thanks for the feedback and apologies for the delayed response, I was on the road and my internet was all wonky this weekend from that ddos attack. I can rework this and get it in the next iteration of the feature/curriculum-expansion branch.

QuincyLarson commented 8 years ago

@HKuz No need to apologize - I'm happy your receptive to making this small change. I hope you had a fun weekend on the road.

alookatommorow commented 7 years ago

@QuincyLarson how is it going with the new curriculum? Is there anything I can do to help?

QuincyLarson commented 7 years ago

@alookatommorow thanks for your offer. We are getting quite close to pushing this to beta. Look for an announcement in the coming weeks. In the meantime, you can help hanging out on our forum and helping us QA some of the new projects we're designing by building them yourself: https://forum.freecodecamp.com/c/meta

alookatommorow commented 7 years ago

Ok, great. Thanks @QuincyLarson