Lesson 15 Flashcards
Encapsulation
Encapsulation is the process of hiding the internal state of an object and restricting or controlling how they can be accessed or modified. Encapsulated attributes can only be accessed or modified through and objects methods
Reasons for encapsulation
Better data control prevents accidental modification of data and promotes modular programming
Three main categories of protection for class attributes
Public, protected, private
A double underscore
double underscore prefixes are mangled, and it offers more protection, but it’s not secure anyone with an understanding of mangling can still have full control of the attribute
A dunder
Thunder or magic method is one that has a double underscore prefix and postfix such as __init__
To control how protected and private attributes are access to modified it is common to define get/set methods
A getter retrieves the value of an attribute.
A setter modifies an attribute (usually with some conditions)
@property
The recommended way of writing getter and sitter methods is to decorate them with at property. To improve readability of the code will maintaining control over how attribute our access and modified.
Version control
Is a system that tracks changes to files over time. It allows multiple people to collaborate on a project while maintaining a history of modification. Enables developers to revert to previous versions, compare changes and work on different features simultaneously without overwriting each others work.
Typical Git Workflow
Remote Repository: A centralized copy of the project that can be accessed by everyone collaborating on the project
Clone: Make a copy of the remote repository and save it on the local machine (local repository)
Local working Directory: A folder on your computer where the files in your project are located. These files reflect the version of the project that is currently checked out plus any uncommitted changes made locally
Add: add a modified filed to the staging area
Staging Area: A sort of check-point that contains snapshots of the project files that are ready to be committed
Commit: Save the files in the staging area to the local repository. This must include a short message describing the changes that are being committed.
Checkout: Make a particular snapshot of the project the current working version. The files in the local working directory will reflect the checked out version.
Pull: Update the local repository with any changes in the remote repository since the last pull or initial clone. Could result in conflicts that need to be manually resolved
Push: upload changes in the local repository. Will result in an error if a collaborator has pushed changes since you last pulled.
Branching/Merging
When we want to add features it is best to create a branch, work on the new features anf then merge the changes back into the main branch.
Main branch
Preserved to be a working production version of the project. Merges to main are usually considered carefully and reviewed by multiple developers
Branch
A separate line of development that allows multiple people to work on different features or fixes without affecting the main codebase.
A branch acts like a copy of the repository where changes can be made independently before merging then back into the main branch.
Merge
Combine the changes from the feature branch into the main branch. Straight forward when no changes to the main branch have been made, since the branch was created. Otherwise things get complicated
Conflict
When merging branches that have changes affecting the same line of a file or conflicting modifications to the project structure. Must be resolved manually.
Workflow to avoid chaos
- keep branches short lived anf avoid large commits
- communicate and coordinate changes
- follow a clear branching strategy(feature branches, hotfix branches, develop branches, release branches)
-regularly pull and merge upstream changes - use clear commit messages
-do code reviews
-resolve merge conflicts early
