|
| 1 | +# Using Classes for encapsulation compared to global variables |
| 2 | + |
| 3 | +This is quick reference for using alternatives to global variables. |
| 4 | +It is not a guide as to which pattern is the best. |
| 5 | + |
| 6 | +The choice between using classes and encapsulation versus global variables depends on the specific requirements and design principles of your code. |
| 7 | + |
| 8 | +In general, using classes and encapsulation is often considered a better practice than relying heavily on global variables. |
| 9 | + |
| 10 | +## Modularity and Organisation: |
| 11 | +Classes allow you to encapsulate related data and behaviour into a single unit, promoting a modular and organised code structure. |
| 12 | + |
| 13 | +With global variables, it can be challenging to maintain a clear structure, and it's easier for variables to be modified unexpectedly, leading to potential bugs. |
| 14 | + |
| 15 | +## Code Reusability: |
| 16 | +Classes promote code reusability since you can create instances of a class in different parts of your code, and each instance can maintain its state independently. |
| 17 | + |
| 18 | + |
| 19 | +Global variables can lead to code that is tightly coupled and less reusable, |
| 20 | +as any part of the code can modify them, making it harder to reason about the behavior of the program. |
| 21 | + |
| 22 | +## Encapsulation: |
| 23 | +Encapsulation, a fundamental principle of object-oriented programming (OOP), |
| 24 | +allows you to hide the implementation details of a class and expose only what is necessary. This helps in reducing dependencies between different parts of the code. |
| 25 | +Global variables lack encapsulation, making it harder to control access to and modification of data, which can lead to unintended side effects. |
| 26 | + |
| 27 | +## Testing and Debugging: |
| 28 | + |
| 29 | +Classes make it easier to test and debug code because you can isolate and test individual components (methods) of a class independently. |
| 30 | +Global variables can make testing and debugging more challenging, as changes to global state can affect the behavior of different parts of the code. |
| 31 | + |
| 32 | +## Namespace Pollution: |
| 33 | + |
| 34 | +Overuse of global variables can lead to namespace pollution, |
| 35 | +where variable names clash and cause unintended consequences. |
| 36 | +Classes provide a way to create isolated namespaces, |
| 37 | +reducing the risk of naming conflicts. |
| 38 | + |
| 39 | + |
| 40 | +While classes and encapsulation are generally recommended, |
| 41 | +it's essential to consider the specific requirements of your project. |
| 42 | +In some cases, using global variables might be appropriate, but it's crucial to be mindful of the potential drawbacks mentioned above. Striking a balance and following good design principles will contribute to more maintainable and scalable code. |
| 43 | + |
| 44 | + |
| 45 | +## Singleton pattern |
| 46 | + |
| 47 | + |
| 48 | +The singleton pattern is a software design pattern that restricts the instantiation of a class to a singular instance. |
| 49 | +One of the well-known "Gang of Four" design patterns. |
| 50 | +A singleton implementation may use lazy initialization in which the instance is created when the static method is first invoked. |
| 51 | + |
| 52 | +## Monostate pattern |
| 53 | + |
| 54 | +The monostate pattern will create instances or objects with their own identity that all share the same internal state. |
| 55 | +It is often referred to as the Borg pattern in reference to The Borg in Star Trek. |
| 56 | +While being individuals in their own right, they all share the same collective consciousness or shared state. |
0 commit comments