Objects and Object Constructors: Add examples of grouping functionality with objects

[takinabradley]

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

• Replaces the "Objects as a design pattern" section of the lesson with content showcasing how objects can be used to group functionality- and not just data.
• The previous content that was there has been moved to a section named "Objects as a data structure"

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

• I have thoroughly read and understand The Odin Project Contributing Guide
• The title of this PR follows the location of change: brief description of change format, e.g. Intro to HTML and CSS lesson: Fix link text
• The Because section summarizes the reason for this PR
• The This PR section has a bullet point list describing the changes in this PR
• If this PR addresses an open issue, it is linked in the Issue section
• If any lesson files are included in this PR, they have been previewed with the Markdown preview tool to ensure it is formatted correctly
• If any lesson files are included in this PR, they follow the Layout Style Guide

[takinabradley]

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 this keyword in inline code blocks.

[JoshDevHub]

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.

[zachmmeyer]

@takinabradley do you need a new review of your work?
Also could you please resolve your conflict?
Otherwise this pull request should be closed.

[takinabradley]

@zachmmeyer

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

[JoshDevHub]

I'm personally fine with this but with a couple of caveats:

1. 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?
2. 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.

[MaoShizhong]

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!

[takinabradley]

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 😄

[MaoShizhong]

Amazing work 🙏 My initial thoughts on the Organizing lessonare below. I'll get to the constructors lesson in due course!

[MaoShizhong]

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.

[takinabradley]

Yeah, I felt the piggy bank assignment covered "Creating an object with contained functionality" well, but it didn't demonstrate things like:

1. The usefulness of grouping data in an object, and passing that around to other functions/methods
2. 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.

[takinabradley]

I'm afraid I'm running into a problem here where it feels really hard let go of a portion of the assignment that gets learners hands-on with private properties.

While the lesson on Factory Functions gives a general overview of how to implement "private variables" with factory functions through closures, I feel it's much more focused on conveying the idea of closures and providing a way to create some form of inheritance with factory functions.

In this lesson I try to create more of a holistic introduction to the concept, so it can be carried over easily to any of the other object creation methods that are covered.

The main article covers using private properties/methods as a way to organize code within an object that doesn't need to be public, and last part of the assignment section tries to tackle instances where private properties can help prevent "bad state".

I did take a stab at rewriting the assignment section to remove the "Extra Credit" section. I landed at a version that splits creating a model of the piggy bank into three parts, with each part corresponding to a main idea in this lesson.

The first part includes creating a couple very simple coin objects, as practice for grouping related data together:

1. Try modelling the behavior of a piggy bank as an object
   1. Create a few 'coin' objects, and assign them to variables to deposit in the piggy bank later.
     - A coin object should contain a `name` property, containing the name of the coin, and a `value` property that give's it's value as a number.
     - For simplicity, using only the smallest subunit of a given currency is acceptable to convey the coin's value.

          Ex: One US quarter may have a value of `25` to represent '25 cents'.

The second focuses on the actual piggy bank, and organizing data and functionality together:

   1. Now, create the piggy bank object:
      1. There should be a public `savings` or `getSavings` property or method that tells users of the piggy bank how much money it contains, as a number. This should give the total value of all the coins currently stored in the piggy bank.
      1. You should be able to interact with your piggy bank object through a public `deposit` method, allowing you to deposit coins. This function should accept one of your coin objects as an argument, and keep it around by storing it in some kind of list.
        - Ensure the piggy bank's savings is updated when you add a coin!
      1. You should be able to get a list of all the coins that are currently stored in the piggy bank through a `coins`/`getCoins` property or method.
      1. Add a `withdraw` method that allows you to remove a specific type of coin from the piggy bank if it's available.
        - Ensure the piggy bank's savings shows the correct value after removing coins!
        - This method should return the coin object that it removes from the list.
      1. Create a method to remove all the money from the jar and start fresh.
      1. You should now have a functional piggy bank object that you can play with in the browser console!

And the third provides practice for potentially common scenarios where you might want to use private methods/properties to avoid bad state:

   1. Lastly, make sure the data on your piggy bank object can't be interacted with in ways you didn't intend! This is an area where private properties/methods come in handy.
      1. You should have exposed the list that the piggy bank uses to track coins through a public property or method. Depending on how you implemented this functionality, modifying this list *from the outside*, without using something like a `deposit` or `withdraw` method could result in coins being added or removed without the savings being updated!

         Additionally, adding an unexpected value to this list by modifying it directly could cause errors within your piggy bank methods (what if somebody adds something that's not a coin object?). 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 and it's objects that they can manipulate to their hearts content without breaking the piggy bank object.          - If a user of your object tries to deposit something that doesn't appear to be a coin with the `deposit` method, throw an error!

      1. Did you use a public property to convey the savings to the consumer of your object? That property can probably be modified willy-nilly to show the wrong value! There are a couple ways you could fix this:
         - Use a public method that calculates the savings every time it's called
         - Another option is to create a private property tracking the savings, and use a public method to return it's value.

I think ultimately this becomes a part of the bigger conversation we're having about how much focus private properties/methods should have at this point. I would personally lean towards approaching the topic earlier, then explaining how one might implement them with each object creation method.

If it's decided it's best to not explore them earlier than we already are, I still feel like there's probably improvements to how we approach the concept later. Maybe it's just my experience and bias, but this alongside just the idea of using objects effectively in general feels like a concept that's people grasp understanding of more through discussion in the server than through the lessons themselves.

[MaoShizhong]

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!

[takinabradley]

I'll do my best to take a look at these throughout the week, thanks for taking a look!

[takinabradley]

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.

[MaoShizhong]

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.

No problem. I'll have to be honest, with a lot of IRL stuff going on combined with Node revamp stuff, I have very little time available for much else on GitHub. So things on my end, if other maintainers aren't able to take over that is, may take time too. I apologise for this taking so damn long to get sorted 😅 I know you've put an incredible amount of work into this and once we do get it in, I'm confident it'll be a great addition to the curriculum.

[takinabradley]

Worked on a bunch of the suggestions the last couple days. Still have to munch on exactly what I want to do with the assignment section, and awaiting a little feedback. Hopefully time can be found on everyone's end to get this through soon 😄