Use Closure to Protect Properties Within an Object from Being Modified Externally - Why is 15 the only number that works in this solution?

Tell us what’s happening:

> " Change how weight is declared in the Bird function so it is a private variable. Then, create a method getWeight that returns the value of weight ."

So why is 15 the only number that works? There is no indication of this in the problem?

Your code so far


function Bird() {
  let weight = 15; 

  this.getWeight = function() {
    return weight; 
  };
}
 

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36.

Link to the challenge:
https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/object-oriented-programming/use-closure-to-protect-properties-within-an-object-from-being-modified-externally

Probably because the test will just check if you added the setter and changed how it was declared, not changing the variable value.

Shouldn’t there be something in the test case that indicates that?

i.e. " Your code should create a method in Bird called getWeight that returns the weight 15".

I understand it’s suppose to implicit but, if it’s the only value the exercise is testing for I think it should be plainly stated.

It asks you to change how it’s declared. If you randomly change other things as well, how could the tests work?

Does that somehow disqualify that the test case doesn’t quantify the exact value?

There a numerous other test cases on freeCodeCamp that directly state the required return value.

Like I previously stated, I get it’s implicit, I just feel the test case is poorly worded.

I put in a pull request to change it, if it goes through we can probably just take this post down. https://github.com/freeCodeCamp/freeCodeCamp/pull/34785

I commented on the PR, personally, I think the assertion test should be changed. It makes no sense that you can just return the number 15 and pass the test. I also don’t understand why the variable is referenced to as a private property.

@lasjorg You should make a pull request and change it.

I might. I just don’t feel super comfortable about the testing part and I believe it would also require local testing which I haven’t gotten into yet. But i guess i can get some help with that if needed.

Private as in it is inaccessible and private as in the OO definition of private, the opposite of public. Practically, there is no way to test what that value assigned to the variable is, because that variable is not exposed. And because it is private, these are all effectively identical:

function Bird() {
  this.getWeight() { return 15; }
}

function Bird() {
  let weight = 15;

  this.getWeight() { return weight; }
}

function Bird() {
  let Z = 'Z';
  let charCode = Z.charCodeAt();

  this.getWeight() { return charCode / 6; }
}

All the test can do is check that the expected return value is correct. Fair enough on the wording, but otherwise the two tests are reasonable for such a tiny thing

I know what the private part means, but calling it a property is clearly wrong.

Surely the test can check that getWeight() is not returning undefined (or maybe better, check for a Truthy value).

From this:

testString: assert((new Bird()).getWeight() === 15, 'Your code should create a method in <code>Bird</code> called <code>getWeight</code> that returns the <code>weight</code>.');

To this:

testString: assert((new Bird()).getWeight() !== undefined, 'Your code should create a method in <code>Bird</code> called <code>getWeight</code> that returns the value of the private variable <code>weight</code>.');

Ah I see what you mean. It is using a closure to directly emulating a private property though, so I think it’s semantics, but yes that change makes it a bit clearer. Technically, no, it isn’t a property, it’s a free variable, but I would say it makes sense to think of them as private properties, particularly given it’s demonstrating how JS can emulate classical OO techniques. Re the test, I guess just checking it is 15 would is the simplest way coupled with a the test description that actually reflects that

1 Like

I mean you can think of them however you like, but you can’t write or say it.

I’m not a seasoned developer but i really think the curriculum in some places is too wishy-washy with the semantics. It should, in my opinion, have much higher priority. Not only will this teach technical communication skills but it will also remove some confusion i have seen.

Technical communication skill is important. If I’m on a team and start to talk about a property, it should be a property. If I’m in a job interview and refer to a local variable as a property then that’s not great.

I understand this platform relies on volunteers and it would be hypocritical of me to criticize and then not make a contribution. But i swear every time i bring up semantics I feel like I’m always shot down with “it’s just semantics”, which i absolutely do not agree with. I also wish there was someone way more knowledgeable than me to help me with my understanding of what I’m suggesting to be incorrect semantics, either agreeing or correcting me. Not just people saying “yeah it’s just not that important, chill out”.

I really don’t mean to be annoying, i only mean well.

1 Like

Yeah, you are right on that. I don’t know how best to explain it to a beginner though, because it is emulating private properties. It’s doing (note this is the current stage 3 proposal for private fields in classes which looks like it’ll land this year):

class Bird {
  #weight = 15

  getWeight() {
    return this.#weight;
  }
}

Or currently, in Typescript:

class Bird {
  private weight = 15;

  constructor () {
    this.weight = weight;
  }

  getWeight() {
    return this.weight;
  }
}

But afaik both of those are just hiding the fact that they’re doing the same as the example on FCC, using a closure to contain a free variable

How about “private variables” rather than private properties? It’s a small point, but one worth examining. They are variables (whether var or let or const), not properties, so it does make sense.

That said, I think it’s a matter of “just wait till you’re a little older, it’ll make sense.” It isn’t right, but as you get more and more familiar with the language, and a little “looser” with the definitions, you may find that conversation with others at or above your skill level will use inaccurate terms.

  • you will sometimes refer to it as a “private method” and other times as a “nested function”.
  • sometimes you’ll call them “private properties” and other times as
    “local variables”.

Context is what defines the term – both context of the term itself, and between both parties in the conversation.

1 Like

Hey, I know you guys are having a lively discussion about encapsulation but it’s pretty far off topic about what I originally posted about. I think we came to the conclusion that the test case should be reworded, i’m just waiting for the merge right now. Can you make another post or move the discussion to a more generalized location? (It’s blowing up my phone with notifications)