Solid understanding on using Javascript ES5 access modifiers and inheritance

[DoubleX 208]

This topic aims to explain how the patterns providing access modifiers and inheritance work in details. You're assumed to have a basic knowledge on using Javascript access modifiers and inheritance.

The focus of this topic corresponds to 'Understanding' in the new version of the Bloom's Taxonomy.

 

Contents

I. Wrapped Prototype

1. Access Modifiers

2. Inheritance

3. Performance

4. Summary

II. Composable Revealing Module

1. Access Modifiers

2. Inheritance

3. Performance

4. Summary

III. Parasitic Inheritance

1. Access Modifiers

2. Inheritance

3. Performance

4. Summary

IV. Reversed Inheritance Hierarchy

1. Access Modifiers

2. Inheritance

3. Performance

4. Summary

V. Reversed Prototype Chain

1. Access Modifiers

2. Inheritance

3. Performance

4. Summary

VI. Summary

 

The topic will explore the following for each pattern:

1. How it provides/Why it doesn't provide private instance variables

2. How it provides/Why it doesn't private static functions/variables

3. How it provides/Why it doesn't protected functions/instance/static variables

4. How it provides/Why it doesn't provide inheritance

 

I'll start to talk about the contents in the upcoming replies in this topic. For now, let's cite the summary in basic knowledge on using Javascript access modifiers and inheritance as both a preparation on what I'm going to cover and a revision on what you're assumed to know already:

 

 

Wrapped Prototype simply declares the function in the global scope, and everything else, including its prototype, inside an immediately-invoked function expression.

This pattern can be desirable when:

1. You don't need/want private/protected instance variables.

2. You don't need/want protected function.

3. You don't mind having duplicated private static constants.

4. You need/want extremely performant object creation codes that scale very well.

5. You need/want/don't mind every subclass to choose its direct parent but not vice versa.

 

Composable Revealing Module simply wraps everything into a named function that's called rather than instantiated.

This pattern can be desirable when:

1. You don't need/want protected function/variables.

2. You don't mind having duplicated private functions/variables.

3. You don't need/want to extend the objects at all or you don't mind suffering from poor scalability.

4. You need/want extremely fast object creation codes, even at the cost of high memory usage, and you don't need/want to extend the objects at all.

5. You need/want private functions/variables.

6. You favor composition over inheritance.

 

Parasitic Inheritance simply wraps everything into a named function that's called by subclasses and instantiated to create new objects.

This pattern can be desirable when:

1. You need/want private and protected functions/variables.

2. You don't mind having duplicated private constants.

3. You don't mind extremely unperformant object creation codes that doesn't scale well.

4. You need/want/don't mind every subclass to choose its direct parent but not vice versa.

5. You don't mind having protected functions/variables compromised, which can compromise the integrity of the whole object as well.

6. You need/want multiple inheritance.

7. You need/want/don't mind subclasses turning the protected functions/variables into public ones.

 

Reversed Inheritance Hierarchy simply wraps everything into a named function, including the declaration of all subclasses, that's instantiated to create new objects.

This pattern can be desirable when:

1. You need/want private and protected functions/variables.

2. You don't mind having duplicated private constants.

3. You don't mind having excessively unperformant object creation codes that lacks scalability.

4. You need/want/don't mind having every parent to choose all its subclasses but not vice versa.

5. You don't mind leading to effectively final classes when no one has access to their source codes anymore.

6. You don't mind managing an unmaintainable mess with a colossal, complex and convoluted inheritance hierarchy.

 

Reversed Prototype Chain simply wraps everything into a named function, including the declaration of all subclasses and defintion of the prototype for creating objects, that's called once to return a function creating objects.

This pattern can be desirable when:

1. You need/want protected functions/variables.

2. You don't need/want private instance variables.

3. You don't mind having duplicated private constants.

4. You don't mind having slightly unperformant object creation codes that's decently scalable.

5. You need/want/don't mind having every parent to choose all its subclasses but not vice versa.

6. You don't mind leading to effectively final classes when no one has access to their source codes anymore.

7. You don't mind managing an unmaintainable mess with a colossal, complex and convoluted inheritance hierarchy.

 

 

Edited March 4, 2017 by DoubleX