Cohesion
Cohesion is about how closely related and focused the methods and variables in a class are. A
highly cohesive class has methods and variables that are all strongly related to a single
purpose. A low-cohesion class has unrelated methods and variables, making it messy and
harder to maintain.
Coupling
Coupling refers to how much one class or module depends on another. It measures how
tightly connected different parts of a program are.
● Tight coupling (bad) → Classes are highly dependent on each other. If one changes,
the other must change too.
● Loose coupling (good) → Classes interact but don't depend on internal details,
allowing them to evolve independently.
Abstraction
Abstraction is about focusing on what something does rather than how it does it. It shows
only the important details and hides the complexity.
● Essential behaviors → It defines what an object can do (its functionality) without
showing how it works internally.
● Implemented using interfaces and inheritance →
○ Interfaces → Define a set of behaviors that a class must implement.
○ Inheritance → Allows a new class to take on behaviors from an existing class
Abstract Data Types: is like a blueprint for how a type of data should behave, without
worrying about how it's actually built or stored in memory. It defines what you can do
with the data but not how it's implemented.
Examples: Lists – Ordered collections where you can access elements by their position.
Maps (Dictionaries) – Key-value pairs that let you quickly lookup values.
Sets – Collections of unique items, without duplicates.
Stacks – "Last in, first out" (LIFO) structure, like a stack of plates.
Queues – "First in, first out" (FIFO) structure, like a line at a store
Encapsulation - in cap(tivity) = protected/private
,Encapsulation is about hiding the inner workings of an object so that only specific parts can
be accessed or modified.
● Hides implementation details → You don’t need to see or change the inner code of an
object to use it.
● Uses access modifiers → Keywords like private, protected, and public control
what data can be accessed from outside the class.
SOLID PRINCIPLES
1. Single Responsibility Principle (SRP) (s = single/one purpose)
● Definition: A class should have only one reason to change. In other words, it should
only have one job or responsibility.
● Why It Matters:
○ Maintainability: When a class has a single responsibility, it's easier to
understand and modify.
○ Reduced Complexity: Changes in one part of the system won’t unexpectedly
affect other parts.
● Example:
Needing a separate class for logging in and authentication
2. Open/Closed Principle (OCP) - open = for use closed = for change
● Definition: A class should be open for extension (you can add new functionality) but
closed for modification (you shouldn’t alter its existing code).
● Why It Matters:
○ Robustness: It minimizes the risk of introducing bugs into existing code.
○ Flexibility: New features can be added by extending the behavior through
inheritance or composition rather than changing existing classes.
● Example:
Instead of modifying a draw() method every time a new shape is added, you can create
an abstract Shape class with a draw() method and extend it with concrete classes like
Circle and Rectangle. The editor can work with the abstract Shape without needing
to know about the specifics of each subclass.
3. Liskov Substitution Principle (LSP) - Base class gotta be the base
, ● Definition: Subclasses should be substitutable for their base classes. This means that if
you have a function that works with a base class, it should work with any subclass
without altering the correctness of the program.
● Why It Matters:
○ Interchangeability: It ensures that a subclass can stand in for its parent class
without unexpected behavior.
○ Reliability: It enforces a contract between the base class and its subclasses.
● Example:
If you have a function that takes an Animal object and calls its makeSound() method,
then passing a Dog or a Cat (both subclasses of Animal) should work seamlessly. If
Dog or Cat altered the expected behavior (e.g., throwing an exception instead of making
a sound), then LSP would be violated.
4. Interface Segregation Principle (ISP) - Interface should be small
● Definition: A class should not be forced to implement interfaces it doesn't use. Instead,
many smaller, specific interfaces are preferable.
● Why It Matters:
○ Decoupling: It prevents a class from becoming bloated with unnecessary
methods.
○ Flexibility: It allows classes to implement only the functionality they need.
● Example:
Suppose you have an interface IMultiFunctionDevice with methods for printing,
scanning, faxing, and copying. A basic printer that only needs printing should not have to
implement scanning or faxing methods. By breaking this interface into smaller ones (e.g.,
IPrinter, IScanner), each device can implement only the relevant interfaces.
5. Dependency Inversion Principle (DIP) - Lots of abstractions
● Definition: High-level modules should not depend on low-level modules. Both should
depend on abstractions (e.g., interfaces). Also, abstractions should not depend on
details; details should depend on abstractions.
● Why It Matters:
○ Loose Coupling: It reduces the dependency on concrete implementations,
making the system more modular and easier to modify.
○ Testability: It becomes easier to substitute real implementations with mocks or
stubs during testing.
● Example:
Instead of a class directly instantiating a MySQLDatabase for data storage, it should
depend on a Database interface. This way, you can easily switch to a different
database (like PostgreSQL) without changing the high-level class. Dependency Injection
is a common way to achieve this principle.
Cohesion is about how closely related and focused the methods and variables in a class are. A
highly cohesive class has methods and variables that are all strongly related to a single
purpose. A low-cohesion class has unrelated methods and variables, making it messy and
harder to maintain.
Coupling
Coupling refers to how much one class or module depends on another. It measures how
tightly connected different parts of a program are.
● Tight coupling (bad) → Classes are highly dependent on each other. If one changes,
the other must change too.
● Loose coupling (good) → Classes interact but don't depend on internal details,
allowing them to evolve independently.
Abstraction
Abstraction is about focusing on what something does rather than how it does it. It shows
only the important details and hides the complexity.
● Essential behaviors → It defines what an object can do (its functionality) without
showing how it works internally.
● Implemented using interfaces and inheritance →
○ Interfaces → Define a set of behaviors that a class must implement.
○ Inheritance → Allows a new class to take on behaviors from an existing class
Abstract Data Types: is like a blueprint for how a type of data should behave, without
worrying about how it's actually built or stored in memory. It defines what you can do
with the data but not how it's implemented.
Examples: Lists – Ordered collections where you can access elements by their position.
Maps (Dictionaries) – Key-value pairs that let you quickly lookup values.
Sets – Collections of unique items, without duplicates.
Stacks – "Last in, first out" (LIFO) structure, like a stack of plates.
Queues – "First in, first out" (FIFO) structure, like a line at a store
Encapsulation - in cap(tivity) = protected/private
,Encapsulation is about hiding the inner workings of an object so that only specific parts can
be accessed or modified.
● Hides implementation details → You don’t need to see or change the inner code of an
object to use it.
● Uses access modifiers → Keywords like private, protected, and public control
what data can be accessed from outside the class.
SOLID PRINCIPLES
1. Single Responsibility Principle (SRP) (s = single/one purpose)
● Definition: A class should have only one reason to change. In other words, it should
only have one job or responsibility.
● Why It Matters:
○ Maintainability: When a class has a single responsibility, it's easier to
understand and modify.
○ Reduced Complexity: Changes in one part of the system won’t unexpectedly
affect other parts.
● Example:
Needing a separate class for logging in and authentication
2. Open/Closed Principle (OCP) - open = for use closed = for change
● Definition: A class should be open for extension (you can add new functionality) but
closed for modification (you shouldn’t alter its existing code).
● Why It Matters:
○ Robustness: It minimizes the risk of introducing bugs into existing code.
○ Flexibility: New features can be added by extending the behavior through
inheritance or composition rather than changing existing classes.
● Example:
Instead of modifying a draw() method every time a new shape is added, you can create
an abstract Shape class with a draw() method and extend it with concrete classes like
Circle and Rectangle. The editor can work with the abstract Shape without needing
to know about the specifics of each subclass.
3. Liskov Substitution Principle (LSP) - Base class gotta be the base
, ● Definition: Subclasses should be substitutable for their base classes. This means that if
you have a function that works with a base class, it should work with any subclass
without altering the correctness of the program.
● Why It Matters:
○ Interchangeability: It ensures that a subclass can stand in for its parent class
without unexpected behavior.
○ Reliability: It enforces a contract between the base class and its subclasses.
● Example:
If you have a function that takes an Animal object and calls its makeSound() method,
then passing a Dog or a Cat (both subclasses of Animal) should work seamlessly. If
Dog or Cat altered the expected behavior (e.g., throwing an exception instead of making
a sound), then LSP would be violated.
4. Interface Segregation Principle (ISP) - Interface should be small
● Definition: A class should not be forced to implement interfaces it doesn't use. Instead,
many smaller, specific interfaces are preferable.
● Why It Matters:
○ Decoupling: It prevents a class from becoming bloated with unnecessary
methods.
○ Flexibility: It allows classes to implement only the functionality they need.
● Example:
Suppose you have an interface IMultiFunctionDevice with methods for printing,
scanning, faxing, and copying. A basic printer that only needs printing should not have to
implement scanning or faxing methods. By breaking this interface into smaller ones (e.g.,
IPrinter, IScanner), each device can implement only the relevant interfaces.
5. Dependency Inversion Principle (DIP) - Lots of abstractions
● Definition: High-level modules should not depend on low-level modules. Both should
depend on abstractions (e.g., interfaces). Also, abstractions should not depend on
details; details should depend on abstractions.
● Why It Matters:
○ Loose Coupling: It reduces the dependency on concrete implementations,
making the system more modular and easier to modify.
○ Testability: It becomes easier to substitute real implementations with mocks or
stubs during testing.
● Example:
Instead of a class directly instantiating a MySQLDatabase for data storage, it should
depend on a Database interface. This way, you can easily switch to a different
database (like PostgreSQL) without changing the high-level class. Dependency Injection
is a common way to achieve this principle.
