Factory Functions : Advanced Objects

Here’s the link to Factory Functions.

My question focuses on Steps 2 & 3. In Step 2, we pass ‘P-500’ and ‘true’ as arguments. Even if we don’t pass them and leave the () blank, Step 3 still works. What was the educating point on including ‘P-500’ and ‘true’ as arguments?

const robotFactory = (model, mobile) => {
  return {
    model: 'model', 
    mobile: 'mobile',
    beep(){
      console.log(`beep Boop`)
    }
  }
}
const tinCan = robotFactory('P-500', true)
tinCan.beep()  // returns 'beep Boop'

I’ve gone over and over this simple exercise and I just don’t understand what I’m supposed to learn. If we use either:

const tinCan = robotFactory('P-500', true)
tinCan.beep()  // returns 'beep Boop'
// both the above and below return 'beep Boop'
const tinCan = robotFactory()
tinCan.beep()  // returns 'beep Boop'

I’m just curious why the directions instructed the student to pass ‘P-500’ and ‘true’ as arguments when then don’t appear to be necessary. How can I view them after they are passed?

1 Like

you do nothing with the arguments passed? You give the model and mobile property string values (which isn’t correct)

the exercise explains a concept (factory), but you then use the factory to only create a single robot. there is a gap between explaining the concept and seeing how useful it would be in a real life project, where you might 10 or even 50 or more robots

1 Like

How do I log those values (‘P-500’, true) of tincan? I want to make them print to the console. I’m going back over all these Advanced Object lessons because the Meal Maker project is kicking my butt.

1 Like

The answer lies in considering what “works” means (bad word, try not to use it)

If work means beeping, does that involve those values? If not, then it doesn’t matter. Did you expect something else to happen, if so, what was that?

What stops you from logging those values? They’re logged same way as anything else aren’t they? console.log(your value here)

1 Like

I guess I sort of thought that after this that there should be a tinCan object hanging out in memory:

const tinCan = robotFactory('P-500', true)

Should be able to console.log the ‘P-500’ and true values of tinCan?

1 Like

that should be possible, yes. You could even log the entire object. If things are are unknown, best thing you can do is gather the information

1 Like

You should be able to log them yes. The question is very weird to me though, if you have a value you can log it.

Maybe you don’t mean log it, maybe you’re asking where it’s located, that has nothing at all to do with logging! But it says right in your code where it gets put, doesn’t it? That’s why I ask what’s stopping you from logging it.

1 Like

The overall point I’ve got here is that there’s probably nothing special going on here, you probably already know everything you need to get in there and look at it yourself to find out what’s up.

Or if you do happen to not know all those things, identifying what information you’re missing likely makes it easy to google (or at least ask a question if it’s non-obvious how to google for it)

1 Like

Yeah, I think i’m struggling with what a Factory Function is for. I’m trying to understand the value of what the page is telling me “A factory function is a function that returns an object and can be reused to make multiple object instances.” So something is created, it exists and it has properties. Right?

The exercise just isn’t pounding it into my head. :slight_smile:

I feel like it is telling me that I can create this Object instance as long as I never want to review the contents I pass to it on creation. Both the example and the exercise only show the results from the object’s method. Example

const ghost = monsterFactory('Ghouly', 251, 'ectoplasm', 'BOO!');
ghost.scare(); // 'BOO!'

What about viewing the other contents of ghost (e.g. ‘Ghouly’, 251, ‘ectoplasm’)?

1 Like

the factory helps so you can make multiple ghost more easily. Lets say for your program you need 50 ghost (you want to build a haunted house), it would be tedious work to declare 50 objects separately. This is where factory comes in

this is unrelated to how to access properties of an object.

1 Like

Where did your function put those values? You have the code right there, all you need to do is read it, right?

Once you’ve figured that out, what operations are therefore required to obtain them from the object?

What’s telling you that you’re prevented from viewing the object? (Let’s say this was a security-sensitive application that needs to hide those values. How would you argue that they can’t be viewed? Or, if you can’t argue for it, then you shouldn’t be able to reach that conclusion, right? Assumptions are great, but they are not facts, they come with some condition. At the very least you need to be able to argue for any conclusion you make - if they come out of the blue then… well the assumption simply shouldn’t exist in the first place, you must have obtained it somehow)

I think

What’s stopping you?

Is a really important question for figuring all these things out.

Identify what information you want.
Identify where that information exists.
Identify what stops you from obtaining it.
For each thing stopping you, start over from step 2
When nothing more stops you, it should be obtainable.

More concretely, you’re wondering where that string and boolean goes. You have a function which accepts them as arguments, what does that function do with them? What’s stopping you from having that information is not having read the function. So you’d go ahead and read it to find out where they went.

Then, if you wanted to print them, you’ve already found out above where they are, so if you don’t know how to get them out, then from knowing the information is inside an object you’d look up operations for objects (reading attributes) and then, since you can now read attributes and you know which object and which attribute, you should now be able to pass the values to console.log


This is a lot like giving bob a lollipop and wondering how to lick it. You’d probably need to ask bob where it went. Maybe bob ate it, in which case you can’t lick it. And, importantly, before thinking about how to specifically lick it you have to first sort out how to find it.

1 Like

Thanks guys. I really appreciate the help. I take notes on all these lessons and have stickies on my monitor to help me soak this stuff in. I also use the codecademy flash cards on my mobile phone. My brain is resisting my determination! :smile:

ionatan, thank you for outlining so well that you understand where I’m struggling. It made me laugh: you’re wondering where that string and boolean goes YES I AM!

heh heh, and I am still struggling. I think I sometimes don’t connect the relationship between the classes I take at codecademy. This is why I’m in the process of retaking them all.

Regarding look up operations for objects (reading attributes), I’ll keep this in mind. Hopefully it will click for me soon.

1 Like

If it turns out that you don’t know how to interact with objects, then there’s quite a lot of things you don’t understand about your code.

You should know what each and every thing in your code does, can’t gloss over it and continue. It is quite mad to write code without knowing what the things you write do. Whenever you encounter something you don’t know, you have to look it up.

For starters, this is an empty object: {}, and you should at a minimum know how to get and set attributes to it. And since that’s … most of what happens in that code, you then probably know enough to reason about the code.

1 Like

I hate to give up on this but, I just can’t figure it out. I completed by the way the Meal Maker protject which some might believe it to be far more complicated than this project. I made sure I understood every line of code. I commented things out and then used console.log to make sure things worked the way I intended. I used all my getters and setters as well. I hope this demonstrates that I understand Objects and Advanced Objects. I went over the lessons leading up to the Meal Maker project about 4 times each! I’m still a beginner however.

The reason I opened this thread is because I just can’t figure out where these arguments went (‘P-500’, true) or how to view them after they are sent.

There’s nothing special about viewing. That’s something else, that’s something you can do when you know where they are.
If you read the function, where do they go?
What does the function do with the values given to it?
For starters, are the names of the parameters mentioned at all in the function body?
And in what way are they mentioned? Some are inside quotes, does this refer to those values in any way, what does quotes do?
And the other mentions are as part of an object literal.

So string literals, and object literals. These are things you can look up. You can experiment with them too.

For example:

let foo = 5
console.log({
  foo: 'foo'
})

There’s an object literal there, and foo is used in the same ways as your parameters in the function. The result is printed to screen. Where did 5 go?
What does foo: at all mean inside an object literal? Reading mdn’s page on object literal is definitely going to answer that, and the quoted one is the literal letters f o o which have nothing at all to do with the value 5.
And then, is anything else not readable in that function? If so, repeat the process of identifying what, and then look for it.


Above all else, what information are you missing? If you can’t read what it does, it must be because you don’t know what something in the code does, right? That gives you something to look up. (I’d be surprised if you couldn’t read the code and think that you understood all of it.)

Okay, persistence seems to be paying off. Thank you for hanging in there with me. A good nights sleep seemed to have helped. The code again from the lesson (modified) is working as expected:

const robotFactory = (model, mobile) => {
  return {
    model, 
    mobile,
    beep(){
      console.log(`beep Boop`)
    }
  }
}

const tinCan = robotFactory('P-500', true)

//tinCan.beep()  // returns 'beep Boop'
//console.log(tinCan) returns '{ model: 'P-500', mobile: true, beep: [Function: beep] }'
//console.log(tinCan.model)  // returns 'P-500'

Perhaps I shouldn’t work on this stuff at night? :slight_smile:

Thanks again. I’m truly grateful.

  {
    model, 
    mobile,
    beep() {
      console.log(`beep Boop`)
    }
  }

That syntax is pretty recent (ecma2015)
I won’t protest against it (it’s quite nice) but I’ll wag my finger a bit and ask you to make sure you’ve read from a trustworthy source that you can indeed write it that way, that you make sure that whatever you write is based on some kind of promise of it being a “thing”. And, that you’re aware that this is still key:value pairs (ie. knowing what it does)

All I’ve been saying comes down to that you should be able to argue for everything you write. When you can do that, you also have the ability to reason about it, isolate and fix issues. In other words, no writing something and praying it does the right thing.


Your function was previously discarding the arguments given to it. They were nowhere to be found. This could be measured by inspecting (for example printing) the return value - those values were not in it. It could also be found out by reading (with confidence of what it says, no guessing) the code, which contains nothing that says to hold on to the values.
Another approach is that, if there’s an expectation of that the values are kept somewhere, then you’ve already decided on what should happen, it pinpoints what to look for. Or if you haven’t decided on what should happen, then the expectation shouldn’t exist. Or something in-between, you haven’t decided what should happen in sufficient detail in which case, figure out what you meant before doing anything else.
That was no great mystery, what was important is the methodology of finding that out because it applies to just about everything else.


Don’t worry about it being a lot to remember. Just look it up when you’re not sure. If you have to look it up enough times then it’ll stick, and if not, then you don’t need to remember anyway. It’s the integrity of knowing what you write that matters.

Thanks again. good advice.