使用点表示法访问对象的属性

（已解决在定单中）✅

此挑战仅接受以下解决方案：

console.log(dog.name);
console.log(dog.numLegs);

但是，我们没有明确声明应使用2个单独的语句，并且以下情况不会通过：

console.log(dog.name, dog.numLegs);

我在想我们应该指定需要制作两个单独的console.log()语句，或者重构测试以接受两种解决方案-我想我更喜欢后一种选择。 有什么想法吗？

使用instanceof验证对象的构造函数：

（已解决在定单中）✅

• 由于某种原因，当编写了正确的解决方案myHouse instanceof House;时，短绒棉绒会抛出警告Expected an assignment of function call and instead saw an expression 。 挑战确实过去了。
• 同样，种子代码本身也会在加载时出现linter警告，提示缺少分号。
• 最后，关于这一点，不确定它是否是有意的，但这可能会有些混乱-在本节之前的挑战中，构造函数的定义如下：

function House(numBedrooms) {
  this.numBedrooms = numBedrooms;
}

但是在这个挑战中，他们切换到了以下语法：

let House = function(numBedrooms) {
  this.numBedrooms = numBedrooms;
}

这并不是一个可能引起混乱的问题。 如果我们同时使用这两种方式，我认为我们应该特别注意区别，否则，只需在整个部分中保持语法一致即可。 虽然我认为可能同时引入两者是一个好主意。

了解自己的属性：

只是对此的观察，并想知道其他观点是什么-但此挑战似乎围绕for...in而不是hasOwnProperty ，而for...in并非如此到目前为止，本节已对此进行了充分的解释。

如果我们假设人们已经完成了其余课程，那么我认为这是可以的，因为至少在“基本数据结构”部分中对此进行了介绍，但是如果我们希望各部分相互独立并且不要求先决条件，我们可能要重温一下？

了解构造函数属性：

（已解决在定单中）✅

无论采用哪种解决方案，这一挑战都会过去：

function joinDogFraternity(candidate) {
  if (candidate instanceof Dog) {
    return true;
  }
  return false;
}

// OR:

function joinDogFraternity(candidate) {
  if (candidate.constructor === Dog) {
    return true;
  }
  return false;
}

我不认为这是一个主要问题，因为本能指示人们会首先尝试向他们提出的解决方案，但是，我也看到这是一个精明的露营者尝试双向尝试并想解决的问题。指出这一点。

我们可以添加一个测试用例"message: 'your solution should use the constructor property'"并使用正则表达式进行验证。

使用继承，这样您就不会重复自己：

我认为这个挑战有点令人困惑。 标题指的是继承，但是，挑战中从未提到继承-我意识到继承与下一个挑战有关，因此露营者会很快发现，但是提出的方式仍然有点令人反感。 另外，在挑战结束时，我们已经制作了Animal超类型，但是我们有点困惑，因为此时Animal并不与Cat绑定Dog 。 为了消除这种混乱，我认为我们可以做些改动：

这个短语来自下一个挑战：

本挑战和下一个挑战将涉及如何在“鸟和狗”内部重用Animal的方法而无需再次定义它们。 它使用一种称为继承的技术。

或许，为了将事情联系起来，可以在此挑战中给出类似于此的更高层次的概述，将所有三个联系在一起，以便了解它们是一个序列，并实际上引入挑战的标题，并使其成为挑战。很明显，在挑战结束时，我们尚未完成。

从超类型继承行为：

（已解决在定单中）✅

超级次要问题-部分种子内容如下：

// Add your code below this line

let duck
let beagle

duck.eat(); // Should print "nom nom nom"
beagle.eat(); // Should print "nom nom nom"

这引发了linter错误。 我将提出以下建议：

超级次要问题-部分种子内容如下：

let duck; // change this line
let beagle; // change this line

duck.eat(); // Should print "nom nom nom"
beagle.eat(); // Should print "nom nom nom"

@ no-stack-dub-sack-这些都是不错的地方，尽管我昨天离线很长时间，但本节没有任何问题。 感谢您详细介绍本节👍这是我的想法（tl；博士-我同意您提出的所有观点）：

• Use Dot Notation to Access the Properties of an Object ：如果有人使用一条console.log语句，则测试将通过。
• Verify an Object's Constructor with instanceof ：我们应该修复丢失的分号，并保持House的定义方式一致。 尽管在JS中有多种处理方式，但无需混淆人们第一次学习它。
• Understanding Own Properties ：关于for...in的观点-我们通常认为可以使用课程中已经涵盖的概念。 露营者可以随意跳来跳去，但是话题不断。 （否则，如果必须在到达重点之前重新发现问题，挑战就会变得漫长/重复）。 就是说，我认为在简短解释语法的示例下添加一个注释可能会有所帮助（“回想一下for...in确实可以...”）
• Understand the Constructor Property ：同意您的指示，以便在说明中使用构造函数进行添加
• Use Inheritance So You Don't Repeat Yourself ：是的，把挑战更好地结合在一起的好点
• Inherit Behaviors from a Supertype ：我们绝对应该添加分号，并且注释也很有用

让我知道您是否要处理这些问题-我要跳到另一部分（可以在一两天内进行处理），或者我们可以根据需要打开此窗口😄

@HKuz酷，谢谢！ 我将结束本节，如果有任何其他意见，请再添加一些评论，然后我们可以做出决定，但是我认为将其开放给Help Wanted将是最好的选择。 会及时向大家发布。

继承后添加方法：

由于以下测试案例，这一挑战有些令人困惑：

Dog should have the bark() method as an own property.

这部分的解决方案正在寻找：

Dog.prototype.bark = function() {
    console.log('Woof!');
};

虽然Dog.prototype.hasOwnProperty('bark')确实返回了true （所以这是正确的），但混乱的根源在这里（来自Iterate Over All Properties ）：

有了信息露营者的知识，他们可能会假设要通过测试，就必须直接在Dog的对象实例上定义bark方法在原型上。

的区别在于，对于实例Dog ， bark将_not_是own属性，但它_is_一个own的属性Dog.prototype 。 因此，这对刚被介绍这些概念的人有些困惑。

最简单的解决方案是将测试用例更改为：

Dog.prototype should have the bark() method as an own property.

虽然，也许一个简短的解释是让营员知道原型的prototype属性实际上是该原型的own属性？ 哇，那是绕口令，是的，这有点令人困惑，我不确定减轻混乱的最佳方法是什么...

使用闭包可保护对象内的属性免于外部修改：

（已解决在定单中）✅

小错字：

我认为应该是“ ...超出bird的定义”。 ？

了解立即调用的函数表达式（IIFE） ：

这个挑战没有大的问题-只是一个建议-虽然我意识到匿名IIFE是更常见的模式（以及下一个挑战中使用的模式），但也许这里是提到IIFE的好地方IIFE错误将更难被发现。

有什么想法吗？

使用IIFE创建模块：

我想对此有所了解...也许@dhcodes或@Greenheart？
我的问题是，我认为挑战不能充分说明为什么IIFE在这种情况下有意义。

该解决方案要求：

let funModule = (function() {
  return {
    isCuteMixin: function(obj) {
      obj.isCute = function() {
        return true;
      };
    },  
    singMixin: function(obj) {
      obj.sing = function() {
        console.log("Singing to an awesome tune");
      };
    }
  };
})();

因此您可以执行以下操作：

function Bird () { }
let duck = new Bird();
funModule.singMixin(duck);
duck.sing();

但是，您可以用不太冗长的方式实现同​​一件事，而根本不需要调用函数，只需定义IIFE返回的对象即可。

挑战说明：

模块模式的优点在于，所有运动行为都可以打包到一个对象中，然后可以由代码的其他部分使用。

但是，因为这根本不需要IIFE，所以我想我会对在此引入概念或找到更强的结合方式的想法提出质疑。这可能会造成混淆/误导，因为露营者可能认为他们需要这样做如果不是这种情况，请实现此模式。

有什么想法吗？

@ no-stack-dub-sack我同意这不是IIFE的最佳示例。 如果提供一个module作为示例会更好吗？

我认为IIFE的核心价值在于您可以创建对象的私有属性和方法。 这对于减少其他人（误）使用您的软件的希望非常有用，以期使事情变得更可靠。

例如，对于您的vanilla js应用程序，您可能有一个小的实用程序模块，在这里您只想公开一些公共方法，因为其余的方法将被更改/删除，并且如果在代码库的其他部分中使用它们会造成麻烦。

这个站点有很多很好的例子： https :

@Greenheart在这里的两个IIFE挑战的最后一个中，它是作为模块模式介绍的，对此我没有任何问题，我只是认为可以更清楚地解释_为什么使用IIFE，以及IIFE不一定必须存在才能实现相同的功能。 我认为这说明了一切：

IIFE的核心价值在于您可以创建对象的私有属性和方法。 这对于减少其他人（误）使用您的软件的希望非常有用，以期使事情变得更可靠。

如果我们能解释一下，并让用户知道“没有IIFE，您就可以实现相同的功能，但是有了IIFE是更好的方法，这就是为什么……”。

当前说明如下：

立即调用的函数表达式（IIFE）通常用于将相关功能分组为单个对象或模块。

为此，我们只需添加：“尽管无需IIFE即可实现相同的功能，但是在这种情况下，IIFE的核心价值在于您可以创建对象的私有属性和方法。这对于减少对象的创建非常有用。其他人可以（错误）使用您的软件并使事情变得更加可靠的方式。”

@ no-stack-dub-sack这个！ ：point_up：

我可以自由地对其进行编译并进行一些小的更改。 我们需要这样的东西：blush：
An <dfn>immediately invoked function expression</dfn> (IIFE) is often used to group related functionality into a single object or module. While the same functionality can be achieved without an IIFE, its core value in this context is that you can create private properties and methods for your objects. This can be very useful for decreasing the ways others can (mis)use your software, and make things much more reliable.

如果以前的挑战中未使用过该术语，则可能使用<dfn> 。

我将继续更新使用点标记法访问对象属性的测试！

继续https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -275974706。

第一个问题是因为linter不希望我们编写本质上是无效代码的表达式（因为我们既不调用函数也不创建变量）。 要解决此问题，建议将结果分配给变量。

第二和第三个问题可以通过更改种子以使用您建议的代码来解决。 将函数对象分配给变量可以在其他地方或根据经验进行讲授。 我认为我们应该与function X () {}保持一致

我会解决这个问题：smile：

修复https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276268534：smile：

修复https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276565338

我将修复https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276245864

我注意到没有挑战可以解决，因此我目前正在从事PR。

了解自己的属性：

（已解决在定单中）✅

这些测试目前允许使用内置方法Object.keys() ，但是我认为露营者可以通过结合使用for...in和Object.hasOwnProperty()来获得更好的练习。

面向对象的编程：遍历所有属性：

（已解决在定单中）✅

刚刚发现此挑战具有相同的问题-它允许使用Object.keys()因为我仍然不认为在这些挑战中应该允许这样做，所以我将创建一个PR，从此行添加测试用例

function Dog(name) {
  this.name = name;
}

Dog.prototype.numLegs = 4;

let beagle = new Dog("Snoopy");

let ownProps = Object.keys(beagle);
let prototypeProps = Object.keys(Dog.prototype);

立即解决此问题：smile：

面向对象的编程：将原型更改为新对象

指导和测试不足。 应该只在prototype上存在describe和eat还是它们是函数？

我认为我们应该添加测试以验证它们是否是功能。

面向对象的编程：记住在更改原型时设置构造函数属性

公关提交：white_check_mark：

此挑战可能应将“构造函数属性”格式化为<code>constructor</code> property以提高可读性和一致性。 你怎么看？

例如，测试消息使用此格式。

一般建议是将let语句替换const以显示最佳实践。 @mpj的这段视频很好地解释了！

面向对象的编程：重置继承的构造方法属性：

公关提交：white_check_mark：

轻微错字： supertype's应该是supertype的

面向对象的编程：使用IIFE创建模块：

公关提交：white_check_mark：

轻微错字：“此处是使用示例：”应更改为“此处是使用示例：”

我正在为https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340设计PR

另一个一般性建议：我认为我们需要更改示例，以便营员不能只是复制示例并更改1-2项内容来完成挑战。

示例应显示概念，但不使用质询itelf使用的属性或方法。 通过这种方式，我认为人们将从每个挑战中学到更多。

沟自定义CSS的引导程序

2017年2月4日星期六，晚上9：11，Samuel Plumppu [email protected]
写道：

另一个一般建议：我认为我们需要更改示例，以便
营员不能只是复制示例并更改1-2项内容来完成
挑战。

示例应显示概念，但不能使用属性或方法
挑战itelf使用的这样，我认为人们会学习
每个挑战都有更多。

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看
https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-277463832 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AX9USApjW3rwocbHWe2yoFLV0RegbkCCks5rZL9SgaJpZM4LxApU
。

@iansibindi似乎您已订阅该存储库的所有消息。 要禁用它，请访问https://github.com/freecodecamp/freecodecamp ，然后单击右上角的“取消监视” 。

抱歉给你带来不便！

@Greenheart我发现即使使用链接也很难追踪其中的每一个-我想我可能应该为每个问题打开一个额外的问题！ 我的意思是在原始评论中添加一个清单。

我将开始对PR进行初步审查，但是您认为如果每个原始评论都有PR，您可以在每个原始评论中添加评论，以便我们跟踪已解决的问题吗？

@ no-stack-dub-sack哈哈我必须承认我自己也不能跟随它，我一直在发布！ ：微笑：

我将在WIP /已修复的每个注释的开头添加一个大的“ PR open”（及其链接）。

@Greenheart完美！ 谢谢！ 我已经审查了前几个PR

我将修复https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277457211

我将修复https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277459744

我将修复https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340

@ no-stack-dub-sack好的，这里还有一些事情要做，但是我今天解决了其中的一些问题！

糟糕，再次将其关闭：laughing：

@Greenheart哇！ 退一步-这件事还有什么要做吗？ 一些重大的改进！

@ no-stack-dub-sack我不知道-根据上面的评论，还有一些事情要做，但是在其他地方可能已经解决了？

我认为它还没有解决。 让我知道你是否有其他想法

大家好！ 我正在关闭此问题，我们可以在出现更多特定问题时重新提出。