Object Oriented Paradigm
4 likes4,653 views
The document provides an overview of programming concepts with a focus on object-oriented programming, highlighting the importance of programming languages, IDEs, and the need for complex structures in modern software. It discusses key principles of object-oriented design, including encapsulation, inheritance, and design patterns, while illustrating concepts with examples and code snippets. Additionally, it emphasizes the significance of following design principles to enhance code readability and maintainability.
Object Oriented Paradigm
- 1. by Hüseyin Ergin Programming Concepts Focused on Object-oriented Programming
- 2. Programming • Just writing some text in a specific format • There are thousands of programming languages! 2
- 3. So, what is the trick here? • A compiler/interpreter does the actual job! • Read text file, interpret the contents, output another file more understandable by machines, less understandable by us 3
- 4. Modern IDEs • Previous slide is not a modern day practice. – At least only computer engineers should do it. • Now we have IDEs (Integrated Development Environment) – Providing • Text editors • Compilers • And many other useful features 4
- 6. What is a program? • Just some sequential lines to instruct the computer what to do! 6
- 7. What is a programming language? • Provides the developer useful constructs – Defining variables – Looping – Conditionals – Many more… • And advanced constructs – Data management – Memory management – Networking – Scheduling 7
- 8. Of course… • The programs are not small any more! – Chrome browser: 17 millions LOC (lines of code) – Office 2013: 45 millions LOC – Facebook: 60 millions LOC • You can’t just put all the lines sequentially and expect someone to understand! • Of course we needed extra structures to handle the complexity 8
- 9. Down to actual examples • Lets see some code in action – DogV1.py • Sequential – DogV2.py • Functional • Exact level of functional details – AreaV1.py – AreaV2.py – AreaV3.py – AreaV4.py 9
- 10. Which language to choose? • According to Google*: – The fastest language is C++ – BUT • If you don’t optimize your code, you may end up slower than other languages – See C++ Dbg vs other languages 10 *Loop Recognition in C++/Java/Go/Scala by Robert Hundt - Google
- 11. Why did I choose Python? • Fast to develop a program – Really fast, no chit-chat • Lightweight IDE • Dynamic typing – I didn’t need to write the type of my variables • Either it is integer, string or any other things • Flexible 11
- 12. Parameters, parameters… • DogV3.py – More parameters mean more generalization of that function • AreaV5.py 12
- 13. How about storing some information? • AreaV6.py – Hiding some information inside of the function • AreaV7.py – More information hidden inside. 13
- 14. Next? • If I can store some information inside a function, – Why not there is a special construct for these kind of scenarios? • There is one already! – Classes 14
- 15. Object-oriented Programming • A.k.a. – Object-oriented paradigm – Object-oriented design – Object-oriented methodology 15
- 16. Wouldn’t it be nice… • If there are specialized Rectangle element that – Knows how many sides are there. – Knows how to calculate its own area. • Whenever I need a Rectangle, I just use this element only. • Whenever I ask for its information, it answers itself. 16 Side = 4 Area = side*side Side Height Base Area = (height*base)/2 height base
- 17. Objects • So everything we infer to have its own properties, methods etc. should be an object 17 Side = 4 Area = side*side Side Height Base Area = (height*base)/2 height base
- 18. Objects • Car, glass, bike, bus – All objects • Dog, cat, person, laptop – Again objects • Running, walking etc… ? – Nop, these are not objects! – These are actions (methods) that can be done by an object • Like a Rectangle can compute its own area • A people can run. • Side, height, numberOfLegs etc… ? – Nop – These are properties (attributes) that can be owned by an object • Like side of a Rectangle. • Numberoflegs of a Person. 18
- 19. Everything can be an object! • It just depends on the context! • Distance between two cities can be an object – If it is the main focus of the problem. • Relationship between two people can be an object – If we are solving a problem about this. 19
- 20. Let’s identify objects! • Company XYZ is a manufacturing company that produces cartoon action figures for big entertainment companies. • This company is using an inventory and tracking system. • The inventory system keeps track of how many of each figurine is stored in each warehouse. • Figures are stored in cases. • Clients order the figurines and the cases are eventually shipped to clients. 20
- 21. Objects Identified • Company XYZ is a manufacturing company that produces cartoon action figurines for big entertainment companies. • This company is using an inventory and tracking system. • The inventory system keeps track of how many of each figurine is stored in each warehouse. • Figures are stored in cases. • Clients order the figurines and the cases are eventually shipped to clients. 21
- 22. Any more? • Company XYZ is a manufacturing company that produces cartoon action figurines for big entertainment companies. • This company is using an inventory and tracking system. • The inventory system keeps track of how many of each figurine is stored in each warehouse. • Figures are stored in cases. • Clients order the figurines and the cases are eventually shipped to clients. 22
- 23. Identify on another example! • An ATM needs to allow a customer to identify themselves – Each customer has a debit card and PIN • Customers should be presented with some kind of menu to help direct them. • Customers can perform two actions: – They should be able to deposit funds – They should be able to withdraw funds upto $200 • These funds must be withdrawn in units of $20 • The ATM should tell some banking software to update the customers’ account at the end of transaction • The ATM should also give the customer some record of the transaction. 23
- 24. Objects identified • An ATM needs to allow a customer to identify themselves – Each customer has a debit card and PIN • Customers should be presented with some kind of menu to help direct them. • Customers can perform two transactions: – They should be able to deposit funds – They should be able to withdraw funds upto $200 • These funds must be withdrawn in units of $20 • The ATM should tell some banking software to update the customers’ account at the end of transaction • The ATM should also give the customer some record of the transaction. 24
- 25. Something unnecessary here • PIN can be a property of either the customer of the debit card! 25
- 26. Object-oriented Languages • Most modern language now supports object- orientation – Java – C++ (C with Classes) – C# – Python – And many more 26
- 27. UML Class Diagrams • Now we know objects, we need a way to design an object-oriented system • This system should be independent from any programming language. • UML is here. – Unified Modeling Language 27
- 28. Basic UML concepts • Classes – Objects • Associations – Relations between objects • Attributes – Properties of an object 28
- 29. Shape System • Abstract class – Abstract method • Generalization • Attributes – Specific to some classes or general for all • Methods 29
- 30. Shape System (Code) • ShapeV1.py – Implementation of Shape and Square – Constructors • ShapeV2.py – Addition of Triangle to the system 30
- 31. Let’s draw our animal system • Specific methods to some classes – According to their abilities 31
- 32. Animal System (Code) • AnimalV1.py – Implementation with Animal, Dog and Cat 32
- 33. Let’s add some spice • An animal has an owner • Association – And multiplicities – Exact read is in arrow direction • 0 or more animals can have 1 owner – But vice-versa is also ok • 1 person can have 0 or more dogs • See the new method in Animal class 33
- 34. Animal System with Owner (Code) • AnimalV2.py – Implementation with Animal, Dog, Cat and Person 34
- 35. Class vs Object • What is the relation between this Person and Huseyin? – Person is a class – Huseyin is an object (conforming to Person class) • Meaning Huseyin is a runtime element • In UML there is a separate diagram for this – Object diagram 35
- 36. Object Diagram • Class Diagram • Code • Object Diagram 36
- 37. More spice for class diagram • Compositions • A room is composed of many chairs and many tables etc. etc. • Code is same as “association” 37
- 38. A little more spice • Interfaces – A blueprint of the implementing classes. – So Dogg should implement these methods • Eat and Travel • Code is same as “abstract” classes. • Animal.java – Implementation of Animal, Dog and Cat 38
- 39. Fundamental Principles of Object-oriented Design • Encapsulation • Inheritance • Abstraction • Polymorphism • Cohesion • Coupling 39
- 40. Encapsulation • Information hiding. – Hide unnecessary information from the public. • EncapsulationV1.java • Public and private methods! 40
- 41. Inheritance • We already see in Animal or Shape system. • Dog inherits methods/attributes of Animal. 41
- 42. Abstraction • Working with something we know how to use but we don’t know how it works internally. • We know animals make sounds and we know how to call it, but we don’t know internals. – Internals defined later on Dog, Cat or Bird classes. 42
- 43. Polymorphism • Having more than one form. • We don’t know how to compute the areas of each shape, but we know it will have different forms in each of the subclasses. 43
- 44. Cohesion • To what degree, a program’s various tasks and responsibilities are related to one another. • Strong cohesion means responsibilities are related to one another. – For example Math class in Java: • It does sin(), cos(), asin(), sqrt(), power(), exp() • It has constants like PI, E etc. – So this class performs only one task: math-related computation • If a class has: – Methods to print something, – Sending an email, – Working with trigonometric functions – How should we name it? Complicated, right? • Strong cohesion helps to build quality code. 44
- 45. Coupling • The extent to which components/classes depend on one another. • CouplingV1.java – Loose coupling • CouplingV2.java – Tight coupling • Loose coupling helps to build quality code! 45
- 46. Advanced Object-oriented Design Principles • S.O.L.I.D. – Single responsibility principle – Open-closed principle – Liskov substitution principle – Interface segregation principle – Dependency inversion principle • Principles by Robert Martin – A known software engineer and pioneer 46
- 47. Single responsibility principle • A class should have one and only one reason to change. – A class should have one job! • SRPv1.java – Problems: • Area calculator is doing so many jobs – Computing areas, printing in some format – It should only sum the areas of the shapes, nothing more. • SRPv2.java – Solution to the printing problem • The logic to print in some different style in handled in a new class 47
- 48. Open-closed principle • Objects should be open to extension, but close to modification – Basically, the classes should be easily extendable without modifying the inner structure. • OCPv1.java – Violation of the principle • OCPv2.java – Now we don’t need to modify sum method each time we add a new shape. 48
- 49. Liskov substitution principle • Every subclass should be substitutable for their parent class. – We should use Dog class instead of Animal class whenever needed. • LSPv1.java – Added a new calculator by extending old one. – We can input this one wherever old one is asked. 49
- 50. Interface segregation principle • A client should never be forced to implement an unnecessary method. • ISPv1.java – Forcing Square to implement volume method, which it doesn’t have. • ISPv2.java – Segregating Shape interface into two to satisfy principle. 50
- 51. Dependency inversion principle • Entities must depend on abstractions/interfaces rather than actual classes. – So that they can be decoupled. • Other definitions: – High-level modules shouldn’t depend on low-level modules. Both should depend on abstractions. – Abstractions should not depend on details, details should depend on abstractions. • DIPv1.java – Manager depends on Worker, and SuperWorker is just sitting there. • DIPv2.java – Now Manager can manage any guy that CanWork. 51
- 52. Principles are done • Now let’s see how we can proceed. 52
- 53. Now the real deal • How will learning object-orientation help me write better codes? • First of all, your code will be more readable – Therefore, more maintainable – As a result, more understandable by “you” later on! – Especially, if you design your UML diagrams with your code too. • Second, is the design patterns. 53
- 54. Design Patterns • People solved same problems for years • And collected good solutions as a collection of something called Design Patterns • First and most famous software related design patterns are in this book: – Design Patterns: Elements of Reusable Object- oriented Software • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 54
- 55. A couple of them • Let’s apply some of the design patterns in real problems and see how it improves our performance or solve our problems. • We will see the structure in UML class diagram. – And see how it works in code. 55
- 56. CHAIN OF RESPONSIBILITY Design Patterns 56
- 57. Chain of Responsibility Design Pattern • Scenario: – Any people sends help emails to help.desk@ua.edu – Any questions are welcome and it will be redirected to correct department – Intuitive solution: • A central help manager that has associations to all departments. 57
- 58. Any principles violated? • What if I want to add more departments? – Open-closed principle • Other problems? – Workload of the help manager? 58
- 59. Chain of Responsibility Structure • Handlers connected with successor links. • The request will be sent to first handler, then follows successors. 59
- 60. New solution after design pattern • Order the departments with respect to the most workload to the least. • A new department can be added easily to the end. 60
- 61. Code example for Chain of Responsibility • CheckAuthority.java – Purchase requests to be approved by: • Manager (upto 5000) • Director (upto 10000) • Vice-president (upto 20000) • President (upto 30000) • Rest needs a board meeting – It starts from manager and to upper level officials. 61
- 63. Flyweight Design Pattern • Scenario: – Creating a forest of trees – Lots and lots of them – Intuitive solution 63
- 64. Any problems? • What happens if I create millions? – Lots of objects, probably some of the attributes are same. • For example color: Green will probably be 95% of the object pool. 64
- 65. Solution: Flyweight Pattern • Structure • Extrinsic states are properties that can be store in client and used as parameter – Like position. • Intrinsic states are stored in flyweight itself. – Like type, color. 65
- 66. New solution after Flyweight • Now we have less TreeModel. – And the position is passed as parameter 66
- 67. New class diagram • FlyweightV1.java • FlyweightV2.java • These are other circle drawing examples, but see the time difference between two implementations. 67
- 68. Conclusion • This was the important parts of object-oriented programming. • Of course, there is a lot more when you dive into different problems. • Just take advantage of these principles and structures. • DON’T FORGET: If you don’t optimize, the fastest language may be slowest. 68
- 69. Questions? 69
- 70. References: • http://www.introprogramming.info/english- intro-csharp-book/read-online/chapter-20- object-oriented-programming-principles/ • https://scotch.io/bar-talk/s-o-l-i-d-the-first- five-principles-of-object-oriented-design • http://gameprogrammingpatterns.com/flyweig ht.html 70