Software engineering / Object
Oriented Programming
The long story why software engineering is as it is
or
How to explain simple concepts with complicated
words
Object Oriented Programming
Before Computers
In the 1840s, Ada Lovelace became the first computer programmer, inspite of the fact that the Analytical
Engine (the computer that she designed the programs for) wasn't ever manufactured.
She was also the first person to suggest that a computer could be more than just an oversized calculator!
Her radical idea was that the numerical values produced by the computer could be used to represent
something other than numbers: symbols, musical notes or well, pretty much anything
Before Computers
Hedy Lamarr
In 1942, during the heyday of her career, Lamarr earned recognition
in a field quite different from entertainment. She and her friend, the
composer George Antheil, received a patent for an idea of a radio
signaling device, or "Secret Communications System," which was a
means of changing radio frequencies to keep enemies from decoding
messages.
“Frequency hopping” was an ingenious way of switching between
radio frequencies in order to avoid a signal being jammed. By
manipulating radio frequencies at irregular intervals between
transmission and reception, the invention formed an unbreakable
code that could prevent secret messages from being intercepted.
It is foundation for today’s mobile phones, Wi-Fi, Bluetooth,
and of course GPS.
Turing Machine
A Turing machine is a mathematical model of computation describing an
abstract machine that manipulates symbols on a strip of tape according
to a table of rules. Despite the model's simplicity, it is capable of
implementing any computer algorithm.
A Turing machine is a general example of a central processing unit
(CPU) that controls all data manipulation done by a computer, with the
canonical machine using sequential memory to store data.
UNIX -> Everything is a file
One of Bell Laboratories Ken Thompson, liked the potential MULTICS (one of
existing OS) had, but felt it was too complex and that the same thing could be
done in simpler way.
In 1969 he wrote the first version of Unix, called UNICS. UNICS stood for
Uniplexed Operating and Computing System. Although the operating system
has changed, the name stuck and was eventually shortened to Unix.
Ken Thompson teamed up with Dennis Ritchie, who wrote the first C compiler.
In 1973 they rewrote the Unix kernel in C. The following year a version of Unix
known as the Fifth Edition was first licensed to universities. The Seventh
Edition, released in 1978, served as a dividing point for two divergent lines of
Unix development.
At the time the first Unix was written, most operating systems developers
believed that an operating system must be written in an assembly language
so that it could function effectively and gain access to the hardware. Not only
was Unix innovative as an operating system, it was ground-breaking in that it
was written in a language (C) that was not an assembly language.
The C language itself operates at a level that is just high enough to be
portable to variety of computer hardware. A great deal of publicly available
Unix software is distributed as C programs that must be complied before use.
GNU is not Unix
GNU is a free software, mass collaboration project
announced by Richard Stallman on September 27, 1983.
Its goal is to give computer users freedom and control in
their use of their computers.
The system's basic components include:
●
●
●
●
●
●
GNU Compiler Collection (GCC)
GNU C library (glibc)
GNU Core Utilities (coreutils)
GNU Debugger (GDB)
GNU Binary Utilities (binutils)
GNU Bash shell
The design of Unix was modular, so it could be
reimplemented piece by piece. The main goal was to
create many other applications to be like the Unix system.
GNU was able to run Unix programs but was not identical
to it
GIT -> saving and blaming
Git is a term of insult denoting an unpleasant, silly,
incompetent, annoying, senile, elderly or childish person
To commit - to do something illegal or something that is
considered wrong:
Version control is a system that records changes to a file
or set of files over time so that you can recall specific
versions later.
Git was heavily inspired by file systems rather than other
VCS, that’s why Git is so different.
Git book
Git Snapshots
Git stores snapshots of the working directory. This allows fast checkout between
commits and branches. But this consumes a lot of memory.
Git thinks about its data more like a stream of snapshots.
GIT Files states
The main thing to remember about Git if you
want the rest of your learning process to go
smoothly. Git has three main states that your
files can reside in: modified, staged, and
committed:
Modified means that you have changed the file
but have not committed it to your database yet.
Staged means that you have marked a
modified file in its current version to go into your
next commit snapshot.
Committed means that the data is safely stored
in your local database.
This leads us to the three main sections of a Git
project: the working tree, the staging area, and
the Git directory.
GIT Commands
A Visual Git Reference
git checkout - Switch branches or restore
working tree files
git commit - creates new snapshot of files
added in staging area
git push - Updates remote refs using local refs
git pull - Incorporates changes from a remote
repository into the current branch
git merge - Join two or more development
histories together
Git rebase - Reapply commits on top of
another base tip
Merge vs Rebase
Merging vs. Rebasing | Git Tutorial
Programming paradigm
Common programming paradigms include:
●
Imperative in which the programmer instructs the machine how to change its state,
○ procedural which groups instructions into procedures,
○ object-oriented which groups instructions with the part of the state they operate on
●
Declarative in which the programmer merely declares properties of the desired result, but not
how to compute it
○ functional in which the desired result is declared as the value of a series of function
applications,
○ logic in which the desired result is declared as the answer to a question about a system
of facts and rules,
○ mathematical in which the desired result is declared as the solution of an optimization
problem
○ reactive in which the desired result is declared with data streams and the propagation of
change
Procedural Paradigm
The procedural programming paradigm is where
program code is divided up into procedures, which
are discrete blocks of code that carry out a single
task. Procedures, also called subroutines or
functions, contain a series of computational steps
to be carried out in the order specified by the
programmer.
Procedural Paradigm
In procedural programming , the function
becomes the most important component of the
program and the functions have unrestricted
access to the global data.
Each procedure or subroutine consist of set of
program statements to complete a specific task .
The program can have may procedures and the
procedure can be called many times in the
program code.
The subroutine or procedure can be written to
perform repetitive task in the program code as
per the program logic. This helps to eliminate
the repetition of code.
Object oriented programming
OOP is paradigm which combines data and actions
(functions) together under the same abstraction
called object
OOP components
Object refers to an instance or a real entity that follows a blueprint (class). The
object is an instance of this blueprint and is used for encapsulating the data and
methods that are defined in a class.
The class provides a common set of functions, methods for its objects to use, and
a bunch of common attributes (placeholders), which then each object can fill to
identify itself.
Attributes
Attributes are the information that is stored. Attributes are defined in the Class
template. When objects are instantiated individual objects contain data stored in the
Attributes field.
The state of an object is defined by the data in the object’s attributes fields. For
example, a puppy and a dog might be treated differently at pet camp. The birthday
could define the state of an object, and allow the software to handle dogs of
different ages differently.
Methods
Methods represent behaviors. Methods perform actions; methods might return
information about an object, or update an object’s data. The method’s code is
defined in the class definition.
Objects instantiation
Constructors are special type of methods that are automatically executed every time you create an object. Also, both class
and constructor have the same name. However, a return type is not there in the constructor.
class Dog {
public:
std::string name;
bool drools;
void barks() {
std::cout << "Woof Woof\n";
};
Dog(std::string dog_name, bool dog_drools){ // this is the constructor
name = dog_name;
drools = dog_drools;
}
};
Constructors
●
Default Constructor: A constructor with no
arguments is called a default constructor. It is the
constructor that is defined implicitly by the compiler.
For C++, the default value that these constructor
gives to a variable is 0.
●
Copy Constructor: It is the constructor that is called
to make a copy of an object. It is invoked in any of
the following cases○
An object of the class is returned by
value
○
An object of the class is passed(to a
function) by value as an argument
○
An object is constructed based on
another object of the same class
○
When compiler generates a temporary
object.
●
Parameterized Constructor: This type of
constructor is used when we want to initialize the
object with certain values. These values can be
passed to the constructors and parameters. These
constructs are also helpful in constructor
overloading.
OOP Principles
●
●
●
●
Inheritance: child classes inherit data and
behaviors from parent class
Encapsulation: containing information in an
object, exposing only selected information
Abstraction: only exposing high level public
methods for accessing an object
Polymorphism: many methods can do the
same task
How to Use
Memes to
Understand
Object Oriented
Programming
Encapsulation
Encapsulation refers to the bundling of data, along
with the methods that operate on that data, into a
single unit.
Encapsulation is the binding of data and methods
into this one entity to define itself and the scope of
its operations.
Class Encapsulation
Our implementation might contain an internal
implementation of a class that stores and processes
specific information. We encapsulate that class by defining
it as private and hiding it from user access.
Access modifiers
You can restrict access to your object’s internal state through
encapsulation and protect sensitive data from unauthorized or
accidental access or interference. This virtue of encapsulation is
popularly referred to as information hiding — because of how it
hides and prevents direct access to your object’s state and
methods.
●
●
●
Private: The most restrictive access modifier, ‘private’,
allows access to the class/object state only through the
class itself (e.g., a class function).
Protected: Being slightly liberal than ‘private’, the
‘protected’ modifier additionally allows access to the
state by other classes in the same package and through
a child class by inheritance for classes outside the
package.
Public: This modifier imposes no restrictions on the
class variable, allowing it to be directly accessed and
modified wherever and whenever required.
Encapsulation
The general rule, enforced by many languages, is that attributes should only
be accessed (retrieved or modified) using methods that are contained
(encapsulated) within the class definition. Data preferably should not be
accessed directly. Instead, getter and setter methods must be provided that
will allow access to the attributes:
●
●
Getter methods return the value of an attribute
Setter methods let you change the value of an attribute
Benefits:
1.
2.
3.
Data Protection: The program runner will not be able to identify
or see which methods are present in the code. Therefore he/she
doesn’t get any chance to change any specific variable or data
and hinder the running of the program.
Flexibility: The code which is encapsulated looks more cleaner
and flexible, and can be changed as per the needs. We can
change the code read-only or write-only by getter and setter
methods. This also helps in debugging the code if needed.
Reusability: The methods can be changed and the code is
reusable.
Inheritance -> hierarchies you should care about
Inheritance is the capability of a class to derive properties and
characteristics from another class. The class whose properties and
methods are inherited is known as the Parent class. And the class
that inherits the properties from the parent class is the Child class.
Types of inheritance
Diamond problem
Ambiguity that arises when two classes B and C inherit from A, and class D
inherits from both B and C. If there is a method in A that B and C have overridden,
and D does not override it, then which version of the method does D inherit: that of
B, or that of C?
Overriding
Overriding is feature that enables a child class to provide
different implementation for a method that is already defined
and/or implemented in its parent class or one of its parent
classes.
The overriden method in the child class should have the same
name, signature, and parameters as the one in its parent class.
Too far - too much - too complicated
Inheritance
Benefits
●
●
Code reuse. The child class may use the code defined in the parent class without
re-writing it.
Inheritance provide a clear model structure which is easy to understand without
much complexity
Problems
●
●
●
Yo-Yo problem. It is pretty hard to understand what a class does without opening up
it’s parent class
Break encapsulation. Creates a tightly coupled relation between child and parent
class. we include all methods and attributes from parent class and expose to the
child class
By using inheritance to reuse the code here, we also introduce a tightly couple,
non-flexible, redundant, complex and does not make sense object.
Inheritance -> Is vs Has
So we got all the benefits of reuse the code,
encapsulate the complexity behind Service class
and create loose coupled object that we can easily
swap to change behavior of the object.
Polymorphism -> Multiple behaviors by abstract representation
Polymorphism is the ability of any
data to be processed in more than
one form.
Real life example of polymorphism, a
person at the same time can have
different roles to play in life.
Like a woman at the same time is a
mother, a wife, an employee and a
daughter. So the same person has to
have many features but has to
implement each as per the situation
and the condition.
What is polymorphism, what is it for,
and how is it used?
Polymorphism -> One interface - Multiple implementations
Create a property, function or an object that
has more than one implementation
Substitute classes that have common
functionality in sense of methods and data.
If you know how to drive a car you can drive
any car, it doesn’t depend on specific car
details such as brand or implementation,
because any car has the same driving
interface.
Interfaces
An Interface is defined as an abstract type used to specify the behavior of a class. An
interface is a blueprint of a class.
An interface is an entity that allows enforcing of certain properties on an object. It is a
description of all functions that an object must have in order to be an "X".
Like a class, an interface can have methods and variables, but the methods declared in
an interface are by default abstract (only method signature, no body).
Interfaces specify what a class must do and not how. It is the blueprint of the class.
An Interface is about capabilities like a Player may be an interface and any class
implementing Player must be able to (or must implement) move(). So it specifies a set
of methods that the class has to implement.
What is the definition of "interface"
in object oriented programming Stack Overflow
Polymorphism forms
-
Dynamic a.k.a Run-Time polymorphism
- Method overriding
(Subclass define own implementation of
methods from super(parent) class)
- Interfaces(Java / C#) / Virtual functions (C++)
-
Static a.ka. Compile-Time polymorphism
- Method overloading
(same methods signature with different
parameters or data types)
- Operator overloading
(operators do various operations
provide new definitions to the existing
operators)
Polymorphism forms
-
Ad-hoc / Overloading / Static Polymorphism
Ad-hoc Polymorphism allows functions having same
name to act differently for different types
-
Inclusion / Subtyping / Dynamic Polymorphism
Inclusion Polymorphism is the ability to use derived
classes through base class
-
Coersion / Casting Polymorphism
Coersion Polymorphism occurs when an object or
primitive of derived(child) class is cast into some super
class.
-
Parametric Polymorphism
Parametric Polymorphism opens a way to use the same
piece of code for different types. It is implemented by the
use of Templates(C++) / Generics (Java / C#)
Abstract Class
Abstract classes can be extended, but not instantiated.
That makes them ideal to represent conceptual
generalizations that don’t exist in your specific domain,
but enable you to reuse parts of your code.
Abstract keyword is used to declare a class or method
to be abstract. An abstract class doesn’t need to
contain any abstract methods. But an abstract method
needs to be declared by an abstract class.
Abstract Method is a method that has just the method
definition but does not contain implementation. A
method without a body is known as an Abstract Method.
Interface vs Abstract Class
What is the difference between an interface and abstract
class? - Stack Overflow
Interface vs Abstract Class
Interface is a contract
Abstract classes are still classes. You can define a behavior for them
SOLID not LIQUID :)
SOLID is an acronym for the first five object-oriented design principles by Robert C.
Martin (also known as Uncle Bob).
These principles establish practices that lend to developing software with considerations
for maintaining and extending as the project grows. Adopting these practices can also
contribute to avoiding code smells, refactoring code, and Agile or Adaptive software
development.
SOLID stands for:
●
●
●
●
●
S - Single-responsiblity Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle
SOLID - Single Responsibility Principle
A class should have one and only one reason to
change, meaning that a class should do one
thing.
In other words, every class should have only one responsibility
If a Class has many responsibilities, it increases the possibility of
bugs because making changes to one of its responsibilities, could
affect the other ones without you knowing.
This principle aims to separate behaviours so that if bugs arise as a
result of your change, it won’t affect other unrelated behaviours.
SOLID - Open-Closed Principle
Objects or entities should be open for
extension but closed for modification.
This means that a class should be extendable without modifying
the class itself.
Modification means changing the code of an existing class, and
extension means adding new functionality.
We should be able to add new functionality without touching the
existing code for the class. This is because whenever we modify
the existing code, we are taking the risk of creating potential
bugs.
SOLID - Liskov Substitution Principle
Every subclass or derived class should be
substitutable for their base or parent class.
This means that, given that class B is a subclass of class A, we
should be able to pass an object of class B to any method that
expects an object of class A and the method should not give any
weird output in that case.
When a child Class cannot perform the same actions as its parent
Class, this can cause bugs.
This principle aims to enforce consistency so that the parent Class
or its child Class can be used in the same way without any errors.
SOLID - Interface segregation principle
A client should never be forced to
implement an interface that it doesn’t
use, or clients shouldn’t be forced to
depend on methods they do not use.
The principle states that many client-specific interfaces
are better than one general-purpose interface. Clients
should not be forced to implement a function they do no
need.
This principle aims at splitting a set of actions into smaller
sets so that a Class executes ONLY the set of actions it
requires.
SOLID - Dependency Inversion Principle
Entities must depend on abstractions, not on
concrete implementations.
It states that the high-level module must not
depend on the low-level module, but they should
depend on abstractions.
- High-level modules should not depend on low-level modules. Both
should depend on the abstraction.
- Abstractions should not depend on details. Details should depend on
abstraction
High-level Module: Class that executes an action with a tool.
Low-level Module: The tool that is needed to execute the action
Abstraction: Represents an interface that connects the two Classes.
This principle aims at reducing the dependency of a high-level Class on
the low-level Class by introducing an interface.
SOLID not LIQUID
●
Single-responsibility principle: Each class should only have a single responsibility. If you see a
class with many lines of code, this can be an indicator that the class serves more than one
responsibility.
●
Open-closed principle: Extending the functionality of your software shouldn’t require you to modify
(a lot) of existing code. If you have to modify (several) existing files to extend functionality, you are
probably not following the open-closed principle. To satisfy the open-closed principle, think about
appropriate design patterns for your problem.
●
Liskov substitution principle: The behavior of subclasses should not deviate from the behavior
that is implemented by the superclass. So, when you are overriding a method of the superclass,
make sure that you are not breaking the invariants of the superclass. If that would be the case, use
of inheritance is not appropriate.
●
Interface segregation principle: To implement the interface segregation principle, don’t lump
different types of functionality in the same interface. Instead, try to write lean interfaces.
●
Dependency inversion principle: The dependency inversion principle can be satisfied by coding
against interfaces rather than concrete implementation
SOLID not LIQUID
Uncle Bob SOLID principles (Video)
The S.O.L.I.D Principles in Pictures | by Ugonna Thelma | Backticks & Tildes |
Medium
SOLID: The First 5 Principles of Object Oriented Design | DigitalOcean
Dependency injection
What is dependency injection? - Stack Overflow
OOP design principles
7 Software Development Principles Boiled Down
to Memes
YAGNI - You Aren’t Gonna Need It
Don’t leave code in the project because you
think it might be useful later on.
OOP design principles
DRY - Don’t Repeat Yourself
Having duplicated code is a waste. You will have to maintain the same logic in two
places, do the tests in two places, and when one place changes, you will have to
remember to change the other one.
OOP design principles
KISS - Keep It Simple and Stupid
Sometimes the smartest solution is the easiest one. Building performant and
efficient code with simplicity is beautiful.
OOP design principles
Big Design Up Front / Architecture First
Before jumping into the implementation part, make sure
it’s all well thought out. By drawing a specific plan you are
saving yourself from possibly having to start from zero
again.
OOP design principles
Avoid Premature Optimization
Premature optimization is the practice that
encourages developers to perform unnecessary
optimization before it’s proven that it is needed.
I think if you apply KISS and YAGNI you shouldn’t
fall for this
Architecture
The fundamental concepts or properties of a
system in its environment embodied in its
elements, relationships, and in the principles
of its design and evolution.
Software Architecture
Defines software elements, relations among them,
and properties of both elements and relations.
Software MV(X) architectures
Classical approach of MV(X) architecture is to put the
entities of the app into one of 3 categories:
●
Views — responsible for the presentation layer (GUI). Could
be anything related to UI, such as buttons, windows, tables,
lists, canvas or any abstraction related to the elements user
can see and interact on the screen.
●
Controller/Presenter/ViewModel — the glue or the mediator
between the Model and the View, in general responsible for
altering the Model by reacting to the user’s actions performed
on the View and updating the View with changes from the
Model.
●
Models — responsible for the domain data or a data access
layer which manipulates the data, think of ‘Person’ or
‘PersonDataProvider’ classes.
MVC -> Massive Monster Model View Controller
In this case, the View is stateless. It is
simply rendered by the Controller once
the Model is changed. Ex. web page
completely reloaded once you press on the
link.
●
The user’s interactions call methods on the
Controller
●
The Controller updates the Model (where
the model is what actually stores state)
●
The Model exposes change listeners to
notify observers that it has changed
●
The View subscribes for changes emitted by
How to Implement MVC Architecture in Java?
the model to update itself
A Beginner’s Guide to MVC Architecture in Java |
upGrad blog
MVC Overview
+
●
It keeps business logic separate.
●
Faster development process
●
Due to large code controller is unmanageable.
●
Bad testability
●
Increased Complexity
MVP -> Model View Presenter
The supposed benefit of MVP is that there is a well-defined contract
between Presenter and View, and it can be verified that “under the
right circumstances, the Presenter calls the right methods on the
View”.
●
●
●
●
The user’s interactions call methods on the Presenter
The Presenter stores state, manages state, and calls methods on the view to
notify it to update itself
The Model is just data
The View receives method calls from the presenter to be notified of
changes to update itself
MVP overview
+
●
●
●
It makes view dumb so that you can swap the
view easily.
Reusable of View and Presenter Code is more
readable and maintainable
Easy testing as business logic separated from
UI
●
●
Tight coupling between View and Presenter
Huge amount of interfaces for interaction
between layers.
Concrete Code Example of MVP [closed] - java
MVP with Testing - Part 1 (MVP Architecture) | Pluralsight
MVVM -> Model View ViewModel
This pattern supports two-way data binding between view
and View model. This enables automatic propagation of
changes, within the state of view model to the View.
Typically, the view model uses the observer pattern to
notify changes in the view model to model.
●
●
●
●
The user’s interactions call methods on the ViewModel
The ViewModel stores state, manages state, and exposes
change events when the state changes
The Model is the data mapped into the observable fields (or
any other form of event emission)
The View subscribes for change events exposed by the
viewmodel to update itself
MVVM Architecture for Beginners — Step by Step Guide
MVVM C# ViewModel's in Examples
MVVM overview
+
●
●
●
No tight coupling between the view and view model
No interfaces between view and model.
Easy to unit testing and code is event-driven.
●
●
You have to create observables for each UI component
because method calls to View are replaced with event
emission.
ViewModel stores the state, so we must be able to
persist/restore the ViewModel state when the process is
re-created
MVC vs MVP vs MVVM
Clean Architecture
Clean Architecture of Uncle Bob
A quick introduction to clean architecture
Architecture?
●
Key feature requirements
It is important to note the prime functionalities that your users
will be working on inside the application.
●
App platform choice
Your idea of features of a good architecture will vary on the
basis of the app platform choice.
●
Development time
There can be some architecture which contains elements that
take up more time to get developed or integrated, while there
can be some which doesn’t take as much time.
●
Developers’ skill set
Ultimately, the choice of the right app architecture will come
down to the skill set your developers carry. There might be
chances that the approach and components that you are
planning to work with have not been worked on by your team
of developers.
Software design patterns
Creational Design Patterns
●
●
Builder
Factory
Structural Design Patterns
●
●
Adapter
Decorator a.k.a Wrapper
Behavioral Design Patterns
●
●
●
Iterator
Observer
Strategy
The Gang of Four are the
authors of the book,
"Design Patterns: Elements
of Reusable Object-Oriented
Software":
Erich Gamma,
Richard Helm,
Ralph Johnson
John Vlissides.
Design Patterns
guide book
Software design patterns: Builder
The pattern allows you to produce different
types and representations of an object using
the same construction code.
The pattern organizes object construction
into a set of steps (buildWalls, buildDoor,
etc.). To create an object, you execute a
series of these steps on a builder object.
The important part is that you don’t need to
call all of the steps. You can call only those
steps that are necessary for producing a
particular configuration of an object.
Builder example
Software design patterns: Factory
Pattern replaces direct object construction calls (using the
new operator) with calls to a special factory method
Subclasses may return different types of products only if
these products have a common base class or interface.
Also, the factory method in the base class should have its
return type declared as this interface.
Factory example
Software design patterns: Adapter
Adapter is a structural design pattern that allows objects with incompatible
interfaces to collaborate.
This is a special object that converts the
interface of one object so that another object
can understand it.
An adapter wraps one of the objects to hide
the complexity of conversion happening
behind the scenes. The wrapped object isn’t
even aware of the adapter. For example, you
can wrap an object that operates in meters
and kilometers with an adapter that converts
all of the data to imperial units such as feet
and miles.
The adapter gets an interface, compatible with one of the
existing objects.
Using this interface, the existing object can safely call the
adapter’s methods.
Upon receiving a call, the adapter passes the request to the
second object, but in a format and order that the second
object expects.
Adapter example
Software design patterns: Decorator / Wrapper
Decorator is a structural design pattern that lets you attach new behaviors to
objects by placing these objects inside special wrapper objects that contain the
behaviors.
Wrapper is the alternative nickname for the
Decorator pattern that clearly expresses the
main idea of the pattern.
A wrapper is an object that can be linked with
some target object. The wrapper contains the
same set of methods as the target and
delegates to it all requests it receives.
However, the wrapper may alter the result by
doing something either before or after it
passes the request to the target.
Decorator Example
Software design patterns: Iterator
The main idea of the Iterator pattern is to extract the
traversal behavior of a collection into a separate object
called an iterator.
In addition to implementing the algorithm itself, an
iterator object encapsulates all of the traversal details,
such as the current position and how many elements are
left till the end. Because of this, several iterators can go
through the same collection at the same time,
independently of each other.
Usually, iterators provide one primary method for fetching
elements of the collection. The client can keep running
this method until it doesn’t return anything, which means
that the iterator has traversed all of the elements.
Iterator example
Software design patterns: Observer
Observer is a behavioral design pattern that allows
some objects to notify other objects about changes in
their state.
The Observer pattern provides a way to subscribe and
unsubscribe to and from these events for any object
that implements a subscriber interface.
Observer design pattern is useful when you are
interested in the state of an object and want to get
notified whenever there is any change. In observer
pattern, the object that watch on the state of another
object are called Observer and the object that is being
watched is called Subject.
Observer example
Observer example
Software design patterns: Strategy
Strategy is a behavioral design pattern that lets
you define a family of algorithms, put each of
them into a separate class, and make their
objects interchangeable.
The Strategy pattern suggests that you take a
class that does something specific in a lot of
different ways and extract all of these algorithms
into separate classes called strategies. The client
decides the actual implementation to be used at
runtime.
Strategy example
Code Smell
Code Smell is any characteristic in the source code of a program that
possibly indicates a deeper problem.
Smells are certain structures in the code that indicate violation of
fundamental design principles and negatively impact design quality.
Code smells are usually not bugs, they are not technically incorrect and do
not prevent the program from functioning. Instead, they indicate weaknesses
in design that may slow down development or increase the risk of bugs or
failures in the future. Bad code smells can be an indicator of factors that
contribute to technical debt.
Code smell with examples
Taxonomy of "Code Smell
The Programmer's Oath by Robert C. Martin (Uncle Bob)
In order to defend and preserve the honor of the profession of computer programmers,
I Promise that, to the best of my ability and judgement:
1.
2.
3.
4.
5.
6.
7.
8.
9.
I will not produce harmful code.
The code that I produce will always be my best work. I will not knowingly allow code that is defective
either in behavior or structure to accumulate.
I will produce, with each release, a quick, sure, and repeatable proof that every element of the code
works as it should.
I will make frequent, small, releases so that I do not impede the progress of others.
I will fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them.
I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing
that decreases that productivity.
I will continuously ensure that others can cover for me, and that I can cover for them.
I will produce estimates that are honest both in magnitude and precision. I will not make promises
without certainty.
I will never stop learning and improving my craft.