4 ms·

My advice is to start of with javascript by forgetting 100% about classes, inheritance, prototypes, and so on. Just use vanilla functions and objects, and when

My advice is to start of with javascript by forgetting 100% about classes, inheritance, prototypes, and so on. Just use vanilla functions and objects, and when in need of something that looks like a class, reach for the revealing module pattern: https://gist.github.com/zcaceres/bb0eec99c02dda6aac0e041d0d4d7bf2 https://gist.github.com/zcaceres/bb0eec99c02dda6aac0e041d0d4...

rustyminnow 5y ago
I've used this pattern before, but run into issues when you want to write tests for "private" functions (like loadSong() in this example). What I've done is name them like _loadSong and expose them anyways, but that doesn't feel great. Is there a better way?
- moron4hire 5y ago
  You don't write tests for private methods.
  - exdsq 5y ago
    Why not?
    - shawnz 5y ago
      The most obvious reason is that they're private and not normally reachable from your test code. But even conceptually there are problems with testing private methods. For example they likely expect to be called only while the class is in some specific state or in the middle of some atomic operation. Otherwise they could have just been made public.
    - bmy78 5y ago
      Because it’s assumed those private methods’ usage happens within public methods, which should be tested. By testing the public methods and all of its use cases you are also testing private ones. That way you can arbitrarily modify private methods without touching the tests (presuming you’re refactoring and don’t need to modify behavior).
      - exdsq 5y ago
        This seems to be building on rocky foundations though. It's unlikely a functions entire test vector gets checked during testing. This is a known risk (you can't test everything) but by leaving all the functions under a public function untested there is no safety net.
        moron4hire 5y ago
        If the code of the private methods cannot be fully exercised through the class' public interface, then that code never executes and should not even be in the function.
  - dotancohen 5y ago
    Of course private methods should be tested. These are unit tests, not functional/integration tests.
    - shawnz 5y ago
      You don't unit test private methods, the "unit" is the exposed surface of the class.
moron4hire 5y ago
Not recommended if you have lots of objects with this interface. Each object will have its own copy of each function. Using a class with the methods in a prototype ensures there is only one copy for all object instances. It also makes specialization and calling super methods super verbose. And you've ultimately not done anything other than reimplementing OOP, poorly.
- bokwoon 5y ago
  You're not supposed to use `super` or specialization with factory functions, call the functions you need instead. OOP inheritance does not belong in this pattern, even if you could hamfist it in (which you've already observed as unwieldy).
zebraflask 5y ago
+1 Maybe I don't write very complicated material, but I can't think of a single time I've needed to use the more OOP features of JS because one of them was the best or only solution.

rustyminnow 5y ago

I've used this pattern before, but run into issues when you want to write tests for "private" functions (like loadSong() in this example). What I've done is name them like _loadSong and expose them anyways, but that doesn't feel great. Is there a better way?

moron4hire 5y ago
You don't write tests for private methods.
- exdsq 5y ago
  Why not?
  - shawnz 5y ago
    The most obvious reason is that they're private and not normally reachable from your test code. But even conceptually there are problems with testing private methods. For example they likely expect to be called only while the class is in some specific state or in the middle of some atomic operation. Otherwise they could have just been made public.
  - bmy78 5y ago
    Because it’s assumed those private methods’ usage happens within public methods, which should be tested. By testing the public methods and all of its use cases you are also testing private ones. That way you can arbitrarily modify private methods without touching the tests (presuming you’re refactoring and don’t need to modify behavior).
    - exdsq 5y ago
      This seems to be building on rocky foundations though. It's unlikely a functions entire test vector gets checked during testing. This is a known risk (you can't test everything) but by leaving all the functions under a public function untested there is no safety net.
      - moron4hire 5y ago
        If the code of the private methods cannot be fully exercised through the class' public interface, then that code never executes and should not even be in the function.
- dotancohen 5y ago
  Of course private methods should be tested. These are unit tests, not functional/integration tests.
  - shawnz 5y ago
    You don't unit test private methods, the "unit" is the exposed surface of the class.

moron4hire 5y ago

Not recommended if you have lots of objects with this interface. Each object will have its own copy of each function. Using a class with the methods in a prototype ensures there is only one copy for all object instances. It also makes specialization and calling super methods super verbose. And you've ultimately not done anything other than reimplementing OOP, poorly.

bokwoon 5y ago
You're not supposed to use `super` or specialization with factory functions, call the functions you need instead. OOP inheritance does not belong in this pattern, even if you could hamfist it in (which you've already observed as unwieldy).

zebraflask 5y ago

+1 Maybe I don't write very complicated material, but I can't think of a single time I've needed to use the more OOP features of JS because one of them was the best or only solution.