A better understanding of Object Oriented Programming. Introduction to DevCoach. Agenda 1. What is OOP 2. Why use it 3. OOP in real life 4. Principles: Abstraction, Encapsulation, Inheritance, Polymorphism 5. Objectifying non-OOP code 6. DevCoach - Learning Framework

1. OBJECTIFY
YOUR CODE
Gabriel Tudorica / 10 June 2019

2. AGENDA
1. What is OOP
2. Why use it
3. OOP in real life
4. Principles
5. Objectifying non-OOP code
6. DevCoach

3. WHAT IS OOP
• What do you think it is?
• Frequently misunderstood
• Top definitions according to google on what is OOP

4. WHAT IS OOP
• Definition #1: Object-oriented programming (OOP) is a programming language
model organized around objects rather than “actions” and data rather than logic

5. WHAT IS OOP
• Definition #2: Object-oriented programming (OOP) is a programming paradigm
based on the concept of “objects”, which can contain data, in the form of fields
(often known as attributes), and code, in the form of procedures (often known as
methods). A feature of objects is an object’s procedures that can access and
often modify the data fields of the object with which they are associated (objects
have a notion of “this” or “self”)

6. WHAT IS OOP
• Definition #3: The four principles of object-oriented programming are
encapsulation,abstraction, inheritance, and polymorphism

7. WHAT IS OOP
• Definition #4: Object-oriented programming (OOP) refers to a type of
computer programming (software design) in which programmers define not only
the data type of a data structure, but also the types of operations (functions) that
can be applied to the data structure.
In this way, the data structure becomes an object that includes both data and
functions. In addition, programmers can create relationships between one object
and another. For example, objects can inherit characteristics from other objects

8. WHAT IS OOP
• Definition #5: Object-oriented programming (OOP) is a software programming
model constructed around objects. This model compartmentalizes data into
objects (data fields) and describes object contents and behavior through the
declaration of classes (methods)

9. WHAT IS OOP
• Technically correct
• No too clear
• Go back to understand it better

10. WHAT IS OOP | PROCEDURAL PROGRAMMING
• Programs written mostly on in a long single file (up to thousands of lines long)
• Top-down approach
• Focused mostly on steps to solve the issue => lack of code structure
• Hard to understand and maintain once the programs got complex/big

11. WHAT IS OOP | PROCEDURAL PROGRAMMING++
• Procedures/routines
• Code reuse (calling routines) instead of copy paste (which is still happening)
• Maintenance issues
• Maintenance is not receiving as much attention as it should during development
• A change was required

12. WHAT IS OOP
• Different way of thinking about programs
• Focus on structure and make maintenance easier
• Added state and behavior
• Principles to ease maintainability
• Simplicity

13. WHAT IS OOP
• (a better) Definition: OOP is a software programming model which aims to
increase the maintainability of the code. This is done by using objects (with state
and behavior) with a specific responsibility to collaborate in order to solve a given
problem. The maintainability property is enforced by the four principles:
abstraction, encapsulation, inheritance and polymorphism.

14. WHAT IS OOP
• It’s not about the syntax, not about the classes, not about the data, it’s about the
messaging between objects to resolve a given problem
• Alan Kay - inventor of the OOP concept http://wiki.c2.com/?AlanKayOnObjects

15. WHY USE OOP
• Maintainability
• Simplicity
• Reduced complexity (complexity kills projects)
• Faster development
• Risk reduction
• Costs

16. OOP IN REAL LIFE
• What do you think?
• Problem: you have an existing chair which needs to be moved from position X to
position Y.

17. OOP IN REAL LIFE
• Procedural style:
• you have to deal with all the details of the chair: what’s it made of, where do the screws
go, how many screws required for each leg/back rest etc
• Initial chair position (position X)
• Move chair to new position (position Y)

18. OOP IN REAL LIFE

19. OOP IN REAL LIFE
• Object Oriented style:
• You have the chair object
• You change the position from X to Y
• Details exist in object, you just don’t need to know all of them to do this operation

20. OOP IN REAL LIFE

21. QUESTIONS?

22. PRINCIPLES | ABSTRACTION - WHAT
• What do you think it is?
• Most straight-forward OOP principle, yet most misunderstood
• Concentrates all essential qualities of a concept
• Captures the essence of a concept, thus simplifying it

23. PRINCIPLES | ABSTRACTION - HOW
• Magic?
• Quite simple
• Logical
• Abstractions are everywhere in real life

24. PRINCIPLES | ABSTRACTION - HOW
• Real-life example #1: It’s a thing which can be used for carrying things. It has
four/five wheels. It runs on some sort of inflammable fluid which through internal
burning puts some gears in motion, thus moving the wheels in the desired
direction. You can steer this thing by rotating a circle shaped tool. It can light up
the way at night if you want to. Oh, and you can also use it for travelling
purposes, internal or external(other cities/countries).

25. PRINCIPLES | ABSTRACTION - HOW
• Crazy dude using a mouthful to describe a basic car
• Example #1 + “abstractification” = car
• Simplification, ignore unnecessary details
• How does the engine work?
• How much fuel does it need to keep the gears running at a certain speed
• What actually happens when I press the acceleration pedal?
• Type and color of the seats
• Don’t need to know all these details to use a car. You need to know just to handle
it

26. PRINCIPLES | ABSTRACTION - HOW
• Essence/Responsibility - Provide mobility through:
• Pedals: accelerate, break, shift gears (optional)
• Steering wheel
• “Stick” to change gears or drive modes
• Another “stick” to signal when you decide to change direction
• A frame with some seats attached over 4 wheels
• I don’t need to understand and think about all low-level details to drive a car

27. PRINCIPLES | ABSTRACTION - HOW
• How would you model a car in code?
• Idea:
• Car.MoveForward()
• Car.Break()
• Car.MoveBackwards()
• Car.TurnLeft()
• Car.TurnRight()

28. PRINCIPLES | ABSTRACTION - HOW

29. PRINCIPLES | ABSTRACTION - HOW
• Real-life example #2: It’s a thing which can allow or block people and/or other
things to move from a room to another. It’s usually made of wood with specific
metal parts. It has some moving gears, allowing it to lock and unlock. The
locking/unlocking require a special tool. It can move from left to right or from
right to left, inward or outward.

30. PRINCIPLES | ABSTRACTION - HOW
• Again, crazy dude using a mouthful to describe a damn door
• Simplification, ignore unnecessary details
• Material it’s made of
• Color
• Type of handle (straight, rounded)
• Handle material
• Type of key
• Don’t need to know all these details to use a door. Think about toddlers using a
door

31. PRINCIPLES | ABSTRACTION - HOW
• Essence/Responsibility - Control access to/from a room through:
• Handle
• Open/close door
• Key
• Lock/unlock door

32. PRINCIPLES | ABSTRACTION - HOW
• How would you model a door in code?
• Idea:
• Door.Open()
• Door.Close()
• Door.Lock(Key)
• Door.Unlock(Key)

33. PRINCIPLES | ABSTRACTION - WHY
• The power of abstraction
• Simplicity
• Easy to work with
• More popular (people love simple to use things)
• The more popular, the more changes it will suffer
• More changes => maintenance
• Maintaining the concept is easier/cheaper/faster/safer
• Think about working with the initial abstraction of the car vs the latter one

34. PRINCIPLES | ABSTRACTION - WHY
• Managing complexity
• The most important technical topic in software development
• Keep your complexity under control by simplifying your concept
• Don’t allow a concept to be more complex than it should be
• Complexity always creeps in and can make your life harder
• Complexity is the number one project killer in software development

35. PRINCIPLES | ABSTRACTION ON MULTIPLE
LEVELS

36. PRINCIPLES | ABSTRACTION ON MULTIPLE
LEVELS
• Can be applied on multiple levels for the same concept
• Higher level car abstraction
• Use Drive() instead of MoveForward(), MoveBackwards(), TurnLeft(), TurnRight()
• Lower level car abstraction
• Instead of Break(), use RegularBrake(), HandBrake() or PanicBrake() for both

37. PRINCIPLES | ABSTRACTION - TAKEAWAY
• You are surrounded by abstractions
• When applied correctly, simplifies things
• When applied incorrectly or not at all, raises the complexity of your code
• Complex code leads to
• Making your life harder than it should
• Makes it easy for you to make mistakes
• Higher risk of killing your project

38. PRINCIPLES | ABSTRACTION - TAKEAWAY
• Simplify whenever you can
• Use the appropriate level of abstraction
• Try to keep your concepts at the same level of abstraction in your code

39. PRINCIPLES | ABSTRACTION - QUESTIONS?

40. PRINCIPLES | ENCAPSULATION - WHAT
• What do you think it is?
• Abstraction simplifies an abstract concept
• Encapsulation is the way the simplification happens: from an abstract concept to
something more tangible
• Abstraction and Encapsulation are complementary

41. PRINCIPLES | ENCAPSULATION - WHAT
• Concepts
• Grouping related ideas in a single concept
• Information hiding
• Grouping ideas in a single concept is started in abstraction and finalized through
encapsulation
• You need to hide information (through encapsulation) to make the object simple
to work with (through abstraction)

42. PRINCIPLES | ENCAPSULATION - HOW
• Information hiding magic (literally hide information)
• Controlling information shared between objects
• Access modifiers (in C#)
• Private
• Protected
• Internal
• Public
• Applied to: classes, properties, members, methods

43. PRINCIPLES | ENCAPSULATION - WHY
• Why not use public modifier everywhere?
• Reduce complexity

44. PRINCIPLES | ENCAPSULATION - WHY
• Example #1: Walking from point A to point B
• Assuming you agree to do it
• Don’t think about how your brain got the trigger and how it sends commands to
your locomotor system

45. PRINCIPLES | ENCAPSULATION - WHY
• Example #1: Walking from point A to point B
• Commands sent by your brain to the locomotor system in this specific order:
• lift left leg about 10 cm from the ground
• lean forward while keeping balance
• move it 40 cm forward
• put left leg down on the ground
• lift right leg about 10 cm from the ground
• …so on and so forth
• repeat until you arrive at point B

46. PRINCIPLES | ENCAPSULATION - WHY
• Example #2: Car - Engine control
• Everybody has access to (public modifiers): Start/Stop engine, Pedals, Fuel tank, Oil tank
• Mechanics have access to (protected modifiers): Filters, Fuel pumps, Oil pumps, Exhaust
etc.
• Producer has access to (internal modifiers): compatible computers for monitoring engines
to use cross models/makes etc.
• Producer has access to (private modifiers): plans to build parts and mechanisms - pumps,
gauges, turbines etc.

47. PRINCIPLES | ENCAPSULATION - WHY
• Imagine having access to all these (all public) when working with an object
• Use parameters to interact with them (distance of foot from ground, when to
start lifting the right leg etc.)
• Added complexity => more frequent mistakes (falling, damage)
• Security => going shopping to the mall having your credit card information
printed on your t-shirt with a big font because it’s “handy” and also you won’t
forget your pin

48. PRINCIPLES | ENCAPSULATION - TAKEAWAY
• Encapsulation is complementary with Abstraction. Can’t have one without the
other
• Focus on simplicity, hide all the information the caller does not need to know in
order to work with the object
• Hide all private data for security reasons
• Adopt the “don’t tell me how to do it, just do it” mindset

49. PRINCIPLES | ENCAPSULATION – QUESTIONS?

50. PRINCIPLES | INHERITANCE - WHAT
• What do you think it is?
• Mechanism for transferring data and behavior of an object (let’s say X) on a
different object (let’s say Y)
• Used to extend the functionality of object X, into a new object, Y
• Powerful mechanism
• Tricky
• Overused => complexity
• Misused => complexity

51. PRINCIPLES | INHERITANCE - WHAT

52. PRINCIPLES | INHERITANCE - HOW
• Several Car objects with different features available based on make and model
• Vehicle construction regulations (breaks, head lights, stop lights, turn signals,
seat belt etc.)
• All makers must comply to these regulations

53. PRINCIPLES | INHERITANCE - HOW
• Create RegulationCompliantCar object to respect all regulations, call it base class
• Each maker can create its own car based on this base class, by extending it
• MercedesCar, HondaCar extend the RegulationCompliantCar in their they way by
adding any additional features they think it best suits their clients, call these
derived classes

54. PRINCIPLES | INHERITANCE - HOW
• Congrats, you just applied inheritance
• You managed to “copy” data and behavior of the base class to the derived
classes without copy-pasting code and managed to extend them by adding
various features as you saw fit from the perspective of the makers

55. PRINCIPLES | INHERITANCE - HOW
• Synonyms
• Base class = super class or parent class
• Derived class = subclass or child class
• Is tricky, you need to know when to apply it and when NOT to apply it

56. PRINCIPLES | INHERITANCE - HOW
• Object relationships
• <is a> relationship => MercedesCar IS A RegulationCompliantCar, makes sense,
inheritance is applied correctly
• <has a> relationship => MercedesCar HAS A RegulationComplientCar, doesn’t make
sense, inheritance is CANNOT be applied correctly. It should be Mercedes Car HAS AN
Engine (Engine is another object), in this case it makes sense, but we are now talking
about composition, not inheritance
• Inheritance != composition
• Multi-level inheritance possible, but should be carefully applied and only if
necessary to avoid complexity

57. PRINCIPLES | INHERITANCE - WHY
• Simplicity
• Avoid copy-paste errors
• Safely update all derived classes
• Reduced risks
• Faster development

58. PRINCIPLES | INHERITANCE - WHY
• Alternative
• You don’t use inheritance
• You have 100+ makes
• Regulation changes, you need airbags for all seats
• How screwed are you to change all 100+ objects?

59. PRINCIPLES | INHERITANCE - TAKEAWAY
• Use the <is a> relationship to test your inheritance and <has a> relationship to
test your composition
• Misused => inheritance != composition
• Overused => inheritance brings complexity, keep your inheritance levels low to
avoid headaches
• Using inheritance for a composition case will add complexity (and headaches) to
your code. Vice versa applies
• Multi-level inheritance applied incorrectly, transforms your headaches into
nightmares fast

60. PRINCIPLES | INHERITANCE – QUESTIONS?

61. PRINCIPLES | POLYMORPHISM - WHAT
• What do you think it is?
• Poly (many)
• Morph (to change, to form)
• The ability of an object to behave differently based on their data type
• Examples
• Rock band: drummer, lead guitarist, bassist, singer => all “Play” differently
• Vehicles: bicycle, motorbike, car, boat, plane => all “Move” differently
• Living organisms: human, cat, butterfly, fish => all “Move” differently
• (Classic) Shapes: triangle, square, rectangle, circle => all use “ComputeArea” differently

62. PRINCIPLES | POLYMORPHISM - WHAT

63. PRINCIPLES | POLYMORPHISM - HOW
• Static polymorphism
• Happens at compile-time
• Synonyms: Compile-Time Binding, Static Binding, Early Binding, Method Overloading
• Method overloading => Add(int a, int b), Add(int a, int b, int c)

64. PRINCIPLES | POLYMORPHISM - HOW
• Dynamic polymorphism
• Happens at run-time
• Synonyms: Run-Time binding, Late binding, Method Overriding
• Method overriding => Musician base class. Guitarist, Bassist, Singer, Drummer derived from
Musician, each having its own implementation of Play()
• Through interfaces => use IMusician interface with Play() method instead of base class.
Guitarist, Bassist, Singer, Drummer would implement the IMusician interface

65. PRINCIPLES | POLYMORPHISM - WHY
• Simplicity
• Keeping your code generic
• Avoid complexity

66. PRINCIPLES | POLYMORPHISM – QUESTIONS?

67. OBJECTIFYING NON-OOP CODE
• Pseudo-code live comparison between non-OOP and OOP code

68. DEVCOACH - WHAT
• Learning framework
• Beginner programmers
• Students
• Anyone willing to learn (career reset)
• Personal project (no companies involved)
• Oct 2017

69. DEVCOACH - WHY
• Help beginner programmers
• Avoid cowboy coding
• Accelerate professional growth

70. DEVCOACH - HOW
• Free Hands-On Practice
• Free tech articles shared through https://www.facebook.com/DevCoachRo
• Blog with free original articles https://devcoachro.wordpress.com
• Structured paid courses for beginners
• 100 hours of theory and hands-on practice
• Bi-weekly, 3 hours / session
• Focused on simplicity
• Full refund possible after 4 sessions (2 weeks)
• Flexible payment options
• Available from fall

71. DEVCOACH - HOW
• Basic Programming Course
• Aimed for students AND career changers
• From scratch
• No programming experience
• No technical background
• Willing to put in the effort to learn
• Build healthy, solid foundations
• Architect your own career
• Looking for a junior role in the software world
• Free demonstration courses coming soon (in 1-2 months)
• Available from fall

72. DEVCOACH - HOW
• Professional Programming Course
• Aimed for anyone who knows the basics of coding
• Want to take it to the next level avoiding cowboy coding
• Learn new concepts
• Thoroughly study and apply known concepts
in better ways
• Looking for a career boost
• Looking for an advanced junior role in the software world
• Free demonstration courses coming soon (in 1-2 months)
• Available from fall

73. DEVCOACH - HOW
• Check all out
• Learn better, faster
• Ask for help/guidance
• Let others know (students, career switch)

74. DEVCOACH – QUESTIONS?
• gabriel.tudorica@iquestgroup.com
• https://www.facebook.com/DevCoachRo
• https://devcoachro.wordpress.com