OOP exercise

[Yanyshpolska]

OOP exercise

Demo |
Code base

The code is submitted in a dedicated feature branch.

Only code files are submitted.

Please, review.

[github-actions]

Hey!

Congratulations on your PR! 😎😎😎

Let's do some self-checks to fix most common issues and to make some improvements to the code before reviewers put their hands on the code.

Go through the requirements/most common mistakes listed/linked below and fix the code as appropriate.

If you have any questions to requirements/common mistakes feel free asking them here or in Students' chat.

When you genuinely believe you are done put a comment stating that you have completed self-checks and fixed code accordingly.

Also, be aware, that if you would silently ignore this recommendation, a mentor can think that you are still working on fixes. And your PR will not be reviewed. 😒

A Tiny JS World -- OOP exercise check list

Relates to A Tiny JS World OOP exercise.

Check-list - definition of done

Minimal requirements to meet:

• Implement a base class to inherit from
• Employ default parameters
• Each species is represented with its own class
• No need to specify species at instantiation
• Classes for species that do not have hands by natural design, do not consequently have hands or any equivalent property and do not inherit such properties from any base classes
• All inhabitants are stored in a container (array or object)
• JS native features are intensively employed (const, let, Array.map|join|forEach|..., etc)
• Object methods like keys, values, entries as well as for...in shouldn't be used as these do not guarantee any particular order of keys/values
• Properties used to form an object presentation string must be explicitly listed/specified; Use Array.map and Array.join to build a presentation string from the list.
• A parent class shouldn't know anything about its children's props. Child classes must have good reasons to assign or refer to any parent's props. There are no such reasons in this task. Method overloading is to the rescue when building an inhabitant's presentation string.
• OOP, SOLID and DRY principles are intensively employed

Optional level up (not required to implement):

• Friends list is a list of objects refs rather than names (strings)
• Cat-woman class is built employing composition rather than inheritance only

Bonus:

• toString magic method; when implemented print(inhabitant) does the job as .toString is called implicitly
• this.constructor.name; when used for output then no need to store species property

Helpful resources:

• ES6 classes cheat-sheet
• Levelling skills up on Tiny JS World

Universal recommendations:

• Give variables and functions meaningful names. Avoid generic names like item, element, key, object, array or their variations. Exception: helper functions that are specifically and intentionally designed to be multipurpose.
• Function names should start with a verb as they denote actions; variables are normally nouns; boolean variables/functions start with is, does, has etc; variable containing multiple entities and functions returning lists contain entity name in plural form.
• Have consistent code style and formatting. Employ Prettier to do all dirty work for you.
• Use common sense or seek for an advice whenever requirements look ambiguous or unclear.

Also take a note of the requirements above and follow them in all your future projects.

By the way, you may proceed to the next task before this one is reviewed and merged.

Sincerely yours,
Submissions Kottachecker 😺

[Yanyshpolska]

Self-check completed.

[stale]

This issue has been automatically marked as stale because there were no activity during last 14 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

А. Чому так?
Найбільш розповсюджена причина: Студент не реагує на коментарі змінами коду і не задає запитань через брак часу або зміну життєвих пріоритетів. Покинуті піари відволікають менторів. Коли у студента з'явиться час, він/вона зможе перевідкрити той самий піар і продовжити роботу.

Б. Що робити, якщо в піарі нема оновлень, оскільки не зрозуміло, що треба зробити?
Варіант 1. Задати питання в самому PR.
Варіант 2. Задати питання в студентському чаті.

В. А якщо я все зробив(ла) і це ментор не рев'юває мої зміни?

1. Переконайся, що ти відреагував(ла) на всі коментарі або кодом, або запитаннями, або відповідями. Напиши в PR і в чаті, що чесно вважаєш, що все зроблено і попроси повторне рев'ю. Якщо щось не зрозуміло, задай запитання.
2. Реагуй на коментарі як менторів, так і інших учасників, включаючи ботів.
3. Не ігноруй прохання типу * "Let's do some self-checks ..." * "Go through the checklist below..." * "mark fulfilled requirements..." * "if you would silently ignore this recommendation, a mentor may think that you are still working on fixes"
   навіть якщо вони написані ботом. Боти помічники і ментори покладаються на те, що прохання і пропозиції бота дотримуються.
   Не лінись піти по лінках в коментарях, погуглити термінологію та скористатись Google Translate.
4. Можливо, у менторів склалися інші пріоритети через роботу, сімейні обставини і т.п. В такому разі, якщо ти зробив(ла) рекомендоване вище, то волай в чаті, що PR позначений stale, наче, все зроблено, а ментори чомусь не реагують - рятуйте!

Г. Хіба недостатньо того, що я додав(ла) коміт із змінами?
Часто буває так, що бачиш новий коміт, ідеш перевіряти, змін багато, доводиться перечитувати весь код. А потім з'ясовується, що одна невеличка зміна "відкладена на потім" чи з'являється ще один коміт і знов треба перечитувати все. Любіть нас, спілкуйтеся з нами - і ми відповімо повною взаємністю.

Традиційна пропозиція: задай питання по вищенаписаному в студентському чаті.

[Yanyshpolska]

Please review. Self-check completed.

[OleksiyRudenko]

@Yanyshpolska a really good job!
A few improvements/optimizations and we are done.

[OleksiyRudenko]

...args is a bad practice because IDE intellisense won't be able to hint what exactly is expected here.

[Yanyshpolska]

Got it.
Fixed.

[OleksiyRudenko]

Benefit from Array#join.
Please explain benefits.

[Yanyshpolska]

I have tried the solution with the Array.join and it worked for me. I found a more effortless and more elegant solution than concatenating strings manually. However in the Array.join I can't control the order of parameters so I need to arrange them correctly in the class itself.
For this particular case, it works fine, so I switched to Array.join.
Thanks for the suggestion.

[OleksiyRudenko]

I didn't look into fixes, but this part "I can't control the order of parameters so I need to arrange them correctly in the class itself." sounds confusing.
What stops you from arranging any items before joining them?
E.g. [ prop9, prop1, prop3].join("")

[OleksiyRudenko]

Took a peek into the changes. Object methods are still a no go. The reasons behind remain the same since pre-OOP TJSW app.

[Yanyshpolska]

My bad. Totally forgot than Object methods are not recommended to be used.

[OleksiyRudenko]

I wonder if we can generalize use of this.constructor.name? Too much repetition across the entire codebase.
Did you try to use it in the base class?

[Yanyshpolska]

Reworked as you suggested.

[OleksiyRudenko]

@Yanyshpolska great job done!

Look also into objects as functions' arguments. Along with destructuring and default values for skipped properties it gives both readability and great flexibility.

function doSomething({ prop3, prop2 = "default value", prop1}) {
  ...
}

const meaningfulName = {
  prop3: 'a',
  prop2: '2',
  prop1: 1,
};

const meaningfulName2 = {
  prop3: 'a',
  prop1: 1,
};

doSomething(meaningfulName);
doSomething(meaningfulName2);