Objects and Object Constructors: Add examples of grouping functionality with objects #27381
Conversation
|
The last commit expanded the idea I already had, but with more detail. This makes the lesson rather long, but is more in the spirit of the content I had in mind when creating the referenced issue. This is also failing Markdownlint because a few descriptive links include the |
takinabradley
changed the title
KevinMulhern
requested review from
a team and
fortypercenttitanium
and removed request for
a team
There was a problem hiding this comment.
I'm gonna come in with a few nits. Will try to get some JavaScript people to review the content soon.
I like a lot of this content, and I think it's nice to dig into the philosophy behind OOP. Maybe one of my main reservations is that the lesson has become quite long now. Might be best to split up the lesson if this ends up getting approved.
javascript/organizing_your_javascript_code/objects_and_object_constructors.md
Outdated
Show resolved
Hide resolved
javascript/organizing_your_javascript_code/objects_and_object_constructors.md
Outdated
Show resolved
Hide resolved
javascript/organizing_your_javascript_code/objects_and_object_constructors.md
Outdated
Show resolved
Hide resolved
javascript/organizing_your_javascript_code/objects_and_object_constructors.md
Outdated
Show resolved
Hide resolved
javascript/organizing_your_javascript_code/objects_and_object_constructors.md
Outdated
Show resolved
Hide resolved
takinabradley
force-pushed
the
why_objects
branch
from
d995c22
to
827614d
Compare
|
@takinabradley do you need a new review of your work? |
|
Yes, I still do. Other than the few nits from Josh, I haven't heard many thoughts here from other maintainers about the issue/PR. I haven't looked at this work in months, though. Going to have to give it a re-read myself and see what I think about the work at present. I've done a good bit of reading and learning since then lol |
There was a problem hiding this comment.
I'm personally fine with this but with a couple of caveats:
- The lesson has become quite long now, from just under 400 lines to now over 600 lines. There are very few lessons in the curriculum that run that long, and I think it's generally a good idea to keep to that pattern. Maybe the "conceptual" stuff around objects could be its own lesson split from the mechanics of constructors/prototypes?
- I'm a ruby guy, and although I have some thoughts about JS curriculum, I don't really have any skin in the game so to speak (lol). So I'd be much more comfortable getting someone from the @TheOdinProject/javascript team to sign off on this as well.
In the meantime, @takinabradley would you be okay fixing the merge conflicts that have popped up with this? Sorry it's taken so long to get this reviewed.
|
A few more chunks of changes there as I reread the lesson and make use of the spaciousness of a whole new lesson. Biggest changes are the the "Objects As Machines" subsection, where I attempted to convey the ideas there in a more concrete way, and the addition of a exercise where learners are to model the behavior of a piggy bank. |
|
Also, should I update the "This PR" information to reflect the extent of the changes as they are now? |
|
|
||
| You may be looking at this code and thinking that you personally prefer to split your code between more functions than you see here, but also recognize that those functions may not really be a useful interaction point for anyone using your object. | ||
|
|
||
| But, there is no rule saying that you can't add those functions to your object as well! A common convention is to prefix methods and properties that you don't intend other people to use with an underscore (`_`). This convention conveys to others that "These things are meant to be used internally by this object, please interact with the other available methods and properties on this object's interface instead". |
There was a problem hiding this comment.
Suggestion: Instead of using underscore to prefix private properties (which is not enforced at runtime at all), imo it'd be better to teach learners about private properties using #property syntax
thoughts?
There was a problem hiding this comment.
The private property syntax is only valid inside of class bodies
There was a problem hiding this comment.
☝️
It's also not an uncommon thing to see in the wild. I would bet material TOP points to even has a few examples of the pattern being used already. IMO this is a decent way to discuss the basic concept without introducing anything overtly fancy- which is kinda the goal of using object literals in the first place. The concepts here can carry over from here into every other lesson on object creation.
A lesson note could be added to stress the fact it's just a common convention and is not enforced. I wouldn't be opposed to it, but I personally think that's already pretty clear.
I know Josh was concerned with the fact that it's kind of legacy. The note can stress that objects are generally created through one of the future object-creation methods and that this specific convention is not often used.
|
This is on my radar but I can't necessarily guarantee I'll be able to get to this properly in the next couple of days. I'm pretty sure I can get through it in chunks over the next week though! |
Thanks! I might have to give it another once-over again myself. I know one thing I was unsure of was the length of the assignments/exercises I ended up writing. Perhaps extracting the "piggy bank" idea into it's own project could be a good idea. Let me know what you think when you get to it 😄 |
javascript/organizing_your_javascript_code/organizing_code_with_objects.md
Show resolved
Hide resolved
javascript/organizing_your_javascript_code/organizing_code_with_objects.md
Outdated
Show resolved
Hide resolved
javascript/organizing_your_javascript_code/organizing_code_with_objects.md
Outdated
Show resolved
Hide resolved
javascript/organizing_your_javascript_code/organizing_code_with_objects.md
Outdated
Show resolved
Hide resolved
javascript/organizing_your_javascript_code/organizing_code_with_objects.md
Outdated
Show resolved
Hide resolved
| Sometimes, you may want to create objects that embody complex concepts rather actual, physical items- similar to the RPS game above. Objects can be used to represent almost anything you can think of, and it's impossible to give a comprehensive list of examples. However, a few examples might be: | ||
|
|
||
| - An object that manages other objects, such as an "inventory" object that contains a list of items, and actions that can be done with those items. | ||
| - An object that can listen for events that happen, and respond appropriately (think of `.addEventListener` on DOM elements) | ||
| - A "Debt" object that keeps track of a debt owed, how much has been paid, and how much of the debt is remaining. | ||
|
|
||
| You may have trouble figuring out what kinds of properties and methods one of these objects might contain at first. One way you might conceptualize these objects might be to imagine them as little 'machines' you're making out of code. | ||
|
|
||
| The properties of the machine could be thought of displays that might show information such as: | ||
|
|
||
| - A list of the items you've collected, the total amount of items you can carry, and how much you're currently carrying | ||
| - A list of functions that are listening for an event | ||
| - The person who owes a particular debt, and the original amount owed. | ||
|
|
||
| The methods of your machine might be akin to buttons and such that make the machinde *do* a specific thing, such as: | ||
|
|
||
| - Remove an item you own from a list, add a new item, upgrade an item, craft a new item | ||
| - Fire all the functions that are listening to a 'click' event, or add a new function to listen to the 'click' event | ||
| - Pay an amount of money towards a debt, and determine how much more money is owed on a debt | ||
|
|
||
| Again, objects can be used to represent almost anything you can think of, the limit is your imagination! |
There was a problem hiding this comment.
I like this section. Two suggestions:
- How about replacing the "listen for events" example with one that's a little more resemblant of a display controller, like what one will likely use in Tic Tac Toe? I think it might be nice to drop a little early hint here than might also help people connect the dots if they revisit this lesson when doing Tic Tac Toe. "Display controller" often ends up being something that's conceptually tricky to get round.
- I'd like for this section to make clear that these concepts will become easier to identify and design through experience, including the use of further concepts/techniques introduced in later lessons. For example, the "you may have trouble..." paragraph:
You may have trouble figuring out what kinds of properties and methods one of these objects might contain at first. These sorts of things come with experience and concepts taught in later lessons can help as well. One way you might conceptualize these objects might be to imagine them as little 'machines' you're making out of code.
There was a problem hiding this comment.
How about replacing the "listen for events" example with one that's a little more resemblant of a display controller, like what one will likely use in Tic Tac Toe? I think it might be nice to drop a little early hint here than might also help people connect the dots if they revisit this lesson when doing Tic Tac Toe. "Display controller" often ends up being something that's conceptually tricky to get round.
I'm assuming you mean something like the ScreenController in Building a House From the Inside out. That seems tricky, and may not perfectly fit in here since in that article it's not something that's implemented as an object, and I think we've been doing a decent job of preventing learners from trying. Also, if they were to try to implement that as an object- I suspect it'd look a lot like the PubSub pattern- which this definitely covers.
If you meant something more like a "view" in the MVC pattern, I'd agree that a lot of learners struggle to create a simple object that just contains some nice DOM utility functions that perform specific actions- divorced from events. We could add something like that in here, but since a module like that might only contain simple functions, and not particularly complex behavior, it's a weird spot to put it. Not opposed to it though to prime learners to think about it.
I'd like for this section to make clear that these concepts will become easier to identify and design through experience, including the use of further concepts/techniques introduced in later lessons. For example, the "you may have trouble..." paragraph:
You may have trouble figuring out what kinds of properties and methods one of these objects might contain at first. These sorts of things come with experience and concepts taught in later lessons can help as well. One way you might conceptualize these objects might be to imagine them as little 'machines' you're making out of code.
I like that idea a lot. I'll get it in there.
| #### Extra credit | ||
|
|
||
| 1. You may have exposed the list that the piggy bank uses to track coins as a public property. Depending on how you implemented the piggy bank, modifying this list without using something like a `deposit` or `withdraw` method on the object could throw some of it's properties out of wack, like the one that tells you the amount of savings you've accrued. | ||
|
|
||
| Additionally, adding an unexpected value to this list by modifying it directly could cause errors within your piggy bank methods. Let's try to ensure that doesn't happen! | ||
| - Indicate that the list of coins the piggy bank uses is a **private property** of the object. | ||
| - Create a **public method** that gives the user a *copy* of the list that they can manipulate to their hearts content without breaking the piggy bank object. | ||
|
|
||
| 1. Try creating a couple 'coin' objects to deposit into the piggy bank instead of using a string. | ||
| - A coin object might contain properties like the name of the coin, and it's value (preferably in the same unit the piggy bank measures it's savings). | ||
| - Make sure that your piggy bank object is still able to keep track of savings and remove coins correctly after this change! | ||
| - After making this change, consider how you are calculating savings for the piggy bank compared to before. Do you prefer working with the objects or the strings more? | ||
| - Consider how the piggy bank might check for a correct string vs checking for an object with the correct properties when depositing. Which seems easier? Does one seem more flexible than the other? |
There was a problem hiding this comment.
I'm not particularly convinced by the value of this extra credit section, especially one that contains so much. Personally, I think the main assignment is absolutely sufficient here. If you feel that anything in the extra credit cannot go, then it ought to be in the main assignment instead of extra credit anyway.
There was a problem hiding this comment.
Yeah, I felt the piggy bank assignment covered "Creating an object with contained functionality" well, but it didn't demonstrate things like:
- The usefulness of grouping data in an object, and passing that around to other functions/methods
- Using private method or properties as a way to prevent "bad state" in objects.
These extra-credit things could help solidify the other things touched upon in this lesson.
I agree the assignment section is unusually long, for an assignment section. The piggy-bank related stuff could potentially be a small project following this lesson.
javascript/organizing_your_javascript_code/organizing_code_with_objects.md
Outdated
Show resolved
Hide resolved
| - Ensure you can still get the correct savings after removing coins! | ||
| 1. Lastly, create a way to remove all the money from the jar and start fresh. | ||
|
|
||
| 1. Try to model something else as an object! Try to keep it simple. When you're done, consider showing off what you've created on [The Odin Project's Discord Channel](https://discord.com/invite/fbFCkYabZB), and tell us how you're feeling about the idea of organizing code into objects. |
There was a problem hiding this comment.
I'm not quite so sure this is necessary as a assignment step but neither do I feel particularly strongly about it. Below is tweaked wording for the link and also using the appropriate href for the creations showcase channel. The server main invite link has been linked many times before this lesson already so I feel it's fine to link straight to a channel here.
| 1. Try to model something else as an object! Try to keep it simple. When you're done, consider showing off what you've created on [The Odin Project's Discord Channel](https://discord.com/invite/fbFCkYabZB), and tell us how you're feeling about the idea of organizing code into objects. | |
| 1. Try to model something else as an object! Try to keep it simple. When you're done, consider showing off what you've created in [our Discord server's "Creations Showcase" channel](https://discord.com/channels/505093832157691914/1013800461465309214). |
There was a problem hiding this comment.
I noticed there was something like this in a couple lessons, and there was also discussion about discord engagement for a little bit after a fireside chat type thing.
I believe I asked about it somewhere, and thoughts on it were inconclusive. I don't feel particularly strongly about it either, but it seems a little fun. If you're erring on the side of leaving it out, tell me and it'll get wiped.
| - [The Principles of Object-Oriented JavaScript](https://www.amazon.com/Principles-Object-Oriented-JavaScript-Nicholas-Zakas/dp/1593275404) book by | ||
| Nicholas C. Zakas is really great to understand OOP in JavaScript, which explains concepts in-depth, which explores JavaScript's object-oriented nature, revealing the language's unique implementation of inheritance and other key characteristics, it's not free but it's very valuable. |
There was a problem hiding this comment.
No manual line break needed.
I'm not 100% sure this book would be an additional resource in scope. Related? Yes. Valuable for some people to dig into now before having had experience with many other things? I feel it's still out of scope and a rabbit hole for many people. Personally, I wouldn't include this resource.
| - [The Principles of Object-Oriented JavaScript](https://www.amazon.com/Principles-Object-Oriented-JavaScript-Nicholas-Zakas/dp/1593275404) book by | |
| Nicholas C. Zakas is really great to understand OOP in JavaScript, which explains concepts in-depth, which explores JavaScript's object-oriented nature, revealing the language's unique implementation of inheritance and other key characteristics, it's not free but it's very valuable. | |
| - [The Principles of Object-Oriented JavaScript](https://www.amazon.com/Principles-Object-Oriented-JavaScript-Nicholas-Zakas/dp/1593275404) book by Nicholas C. Zakas is really great to understand OOP in JavaScript, which explains concepts in-depth, which explores JavaScript's object-oriented nature, revealing the language's unique implementation of inheritance and other key characteristics, it's not free but it's very valuable. |
There was a problem hiding this comment.
I believe this was in the original Objects and Object Constructors lesson at some point, but may have been removed.
It might be worth tucking it into the Object Constructors lesson here. I gave it a very quick read a while ago after doing the JS course, and while I didn't find it valuable personally, I think for the learner going over this stuff for the first time it could be appropriate and give some insight. It may be easier for them to make sense of now too, after adding the "Organizing Code with Objects" lesson.
Since it's not particularly updated, it uses object constructors primarily to explore classical inheritance a little bit (but not particularly in-depth). It may be worth noting that it's a bit dated, if it's to be added back.
Let me know what you think about moving it back into the Object Constructors lesson, or just wiping it out all together.
There was a problem hiding this comment.
Didn't initially clock that the changes are mainly in the new lesson instead of across both 😅 Just the one punctuation nit then for the constructors lesson.
Once the other review is addressed, we can sort out the website repo PR for adding the new lesson to the curriculum and pathways.
Looking forward to seeing this in the curriculum!
javascript/organizing_your_javascript_code/objects_and_object_constructors.md
Outdated
Show resolved
Hide resolved
|
I'll do my best to take a look at these throughout the week, thanks for taking a look! |
Co-authored-by: MaoShizhong <[email protected]>
Change 'functions on an object' to 'functions in an object' Co-authored-by: MaoShizhong <[email protected]>
replace it's with its Co-authored-by: MaoShizhong <[email protected]>
Co-authored-by: MaoShizhong <[email protected]>
Co-authored-by: MaoShizhong <[email protected]>
Co-authored-by: MaoShizhong <[email protected]>
…public interface comes with experience
|
Sorry for the hold up. I'm not exactly waiting on any responses, it's just been hard to find time to sit down and work on the rest of the changes properly this week. Hopefully tomorrow night, or this weekend, I'll try and work in the rest of the suggestions. |
Because
I feel that the content in the Organizing Your JavaScript Code section of the curriculum rushes too quickly into all sorts of fancy features and ways to create objects, without giving learners a very great foundation on why we're bothering to teach them all that stuff in the first place.
This PR
Issue
Closes #27375
Additional Information
I do feel that this PR starts to clutter up the lesson, and that perhaps this lesson could be broken into two or three different ones- but I feel this is about the easiest way we can gently start to introduce these ideas to learners within the current structure of the curriculum.
Pull Request Requirements
location of change: brief description of changeformat, e.g.Intro to HTML and CSS lesson: Fix link textBecausesection summarizes the reason for this PRThis PRsection has a bullet point list describing the changes in this PRIssuesection