Download as PDF, PPTX
![37 // Animals class - main application public class Animals { public static void main(String[] args) { Dog dog = new Dog(); dog.bark(); Cat cat = new Cat(); cat.meow(); } } // output woof meow](https://image.slidesharecdn.com/introductiontoobject-orientedprogrammingdesignprinciples-180318221835/75/Introduction-to-Object-Oriented-Programming-Design-Principles-37-2048.jpg)
![40 // Animals class - main application (revised) public class Animals { public static void main(String[] args) { Animal dog = new Dog(); dog.makeNoise(); Animal cat = new Cat(); cat.makeNoise(); } } // output woof meow](https://image.slidesharecdn.com/introductiontoobject-orientedprogrammingdesignprinciples-180318221835/75/Introduction-to-Object-Oriented-Programming-Design-Principles-40-2048.jpg)
Uploaded byMichael Redlich
Introduction to Object Oriented Programming & Design Principles
The document presents an introduction to Object-Oriented Programming (OOP) and design principles, discussing key concepts such as data encapsulation, inheritance, and polymorphism. It highlights various OOP languages and contrasts OOP with traditional programming paradigms, emphasizing the importance of creating flexible and maintainable designs. The presentation also includes live demonstrations and information on local user groups and upcoming events related to OOP.
Introduction to Object Oriented Programming & Design Principles
- 1. 1 Introduction to OOP &Design Principles Trenton Computer Festival March 17, 2018 Michael P. Redlich @mpredli about.me/mpredli/
- 2. Who’s Mike? • BSin CS from • “Petrochemical Research Organization” • Java Queue News Editor, InfoQ • Ai-Logix, Inc. (now AudioCodes) • Amateur Computer Group of New Jersey 2
- 3. Objectives (2) • Object-OrientedProgramming • Object-Oriented Design Principles • Live Demos (yea!) 3
- 4.
- 5. Some OOP Languages •Ada • C++ • Eiffel • Java • Modula-3 • Objective C • OO-Cobol • Python • Simula • Smalltalk • Theta 5
- 6. What is OOP? •A programming paradigm that is focused on objects and data • as opposed to actions and logic • Objects are identified to model a system • Objects are designed to interact with each other 6
- 7. OOP Basics (1) •Procedure-Oriented • Top Down/Bottom Up • Structured programming • Centered around an algorithm • Identify tasks; how something is done • Object-Oriented • Identify objects to be modeled • Concentrate on what an object does • Hide how an object performs its task • Identify behavior 7
- 8. OOP Basics (2) •Abstract Data Type (ADT) • user-defined data type • use of objects through functions (methods) without knowing the internal representation 8
- 9. OOP Basics (3) •Interface • functions (methods) provided in the ADT that allow access to data • Implementation • underlying data structure(s) and business logic within the ADT 9
- 10. OOP Basics (4) •Class • Defines a model • Declares attributes • Declares behavior • Is an ADT • Object • Is an instance of a class • Has state • Has behavior • May have many unique objects of the same class 10
- 11. OOP Attributes • Four(4) Main Attributes: • data encapsulation • data abstraction • inheritance • polymorphism 11
- 12. Data Encapsulation • Separatesthe implementation from the interface • A public view of an object, but implementation is private • access to data is only allowed through a defined interface 12
- 13. Data Abstraction • Amodel of an entity • Defines a data type by its functionality as opposed to its implementation 13
- 14. Inheritance • A meansfor defining a new class as an extension of a previously defined class • The derived class inherits all attributes and behavior of the base class • “IS-A” relationship • Baseball is a Sport 14
- 15. Polymorphism • The abilityof different objects to respond differently to the same function • From the Greek meaning “many forms” • A mechanism provided by an OOP language as opposed to a programmer- provided workaround 15
- 16. Advantages of OOP •Interface can (and should) remain unchanged when improving implementation • Encourages modularity in application development • Better maintainability of code • Code reuse • Emphasis on what, not how 16
- 17. Classes (1) • Auser-defined abstract data type • Extension of C structs • Contain: • constructor • destructor • data members and member functions (methods) 17
- 18. Classes (2) • Static/Dynamicobject instantiation • Multiple Constructors: • Sports(void); • Sports(char *,int,int); • Sports(float,char *,int); 18
- 19. Classes (3) • Classscope (C++) • scope resolution operator (::) • Abstract Classes • contain at least one pure virtual member function (C++) • contain at least one abstract method (Java) 19
- 20. Classes (3) • AbstractClasses • contain at least one pure virtual member function (C++) • contain at least one abstract method (Java) 20
- 21. Abstract Classes • Purevirtual member function (C++) • virtual void draw() = 0; • Abstract method (Java) • public abstract void draw(); 21
- 22.
- 23. Static Instantiation (C++) • Objectcreation: • Baseball mets(“Mets”,97,65); • Access to public member functions: • mets.getWin(); // returns 97 23
- 24. Dynamic Instantiation (C++) • Objectcreation: • Baseball *mets = new Baseball(“Mets”,97,65); • Access to public member functions: • mets->getWin(); // returns 97 24
- 25. Dynamic Instantiation (Java) • Objectcreation: • Baseball mets = new Baseball(“Mets”,97,65); • Access to public member functions: • mets.getWin(); // returns 97 25
- 26. Deleting Objects (C++) Baseballmets(“Mets”,97,65); // object deleted when out of scope Baseball *mets = new Baseball(“Mets”,97,65); delete mets; // required call 26
- 27. Deleting Objects (Java) Baseballmets = new Baseball(“Mets”,97,65); // automatic garbage collection or: System.gc(); // explicit call 27
- 28.
- 29. What are OODesign Principles? • A set of underlying principles for creating flexible designs that are easy to maintain and adaptable to change • Understanding the basics of OOP isn’t enough 29
- 30. Some OO Design Principles(1) • Encapsulate WhatVaries • Program to Interfaces, Not Implementations • Favor Composition Over Inheritance • Classes Should Be Open for Extension, But Closed for Modification 30
- 31. Some OO Design Principles(2) • Strive for Loosely Coupled Designs Between Objects That Interact • A Class Should Have Only One Reason to Change 31
- 32. Encapsulate What Varies • Identifyand encapsulate areas of code that vary • Encapsulated code can be altered without affecting code that doesn’t vary • Forms the basis for almost all of the original Design Patterns 32
- 33. 33 // OrderCars class publicclass OrderCars { public Car orderCar(String model) { Car car; if(model.equals(“Charger”)) car = new Dodge(model); else if(model.equals(“Corvette”)) car = new Chevrolet(model); else if(model.equals(“Mustang”)) car = new Ford(model); car.buildCar(); car.testCar(); car.shipCar(); } }
- 34.
- 35. Program to Interfaces, NotImplementations • Eliminates being locked-in to a specific implementation • An interface declares generic behavior • Concrete class(es) implement methods defined in an interface 35
- 36. 36 // Dog class publicclass Dog { public void bark() { System.out.println(“woof”); } // Cat class public class Cat { public void meow() { System.out.println(“meow”); } }
- 37. 37 // Animals class- main application public class Animals { public static void main(String[] args) { Dog dog = new Dog(); dog.bark(); Cat cat = new Cat(); cat.meow(); } } // output woof meow
- 38. 38 // Animal interface publicinterface Animal { public void makeNoise(); }
- 39. 39 // Dog class(revised) public class Dog implements Animal { public void makeNoise() { bark(); } public void bark() { System.out.println(“woof”); } // Cat class (revised) public class Cat implements Animal { public void makeNoise() { meow(); } public void meow() { System.out.println(“meow”); } }
- 40. 40 // Animals class- main application (revised) public class Animals { public static void main(String[] args) { Animal dog = new Dog(); dog.makeNoise(); Animal cat = new Cat(); cat.makeNoise(); } } // output woof meow
- 41.
- 42. Favor Composition Over Inheritance •“HAS-A” can be better than “IS-A” • Eliminates excessive use of subclassing • An object’s behavior can be modified through composition as opposed through inheritance • Allows change in object behavior at run- time 42
- 43. Classes Should Be Openfor Extension... • ...But Closed for Modification • “Come in,We’re Open” • extend the class to add new behavior • “Sorry,We’re Closed” • the code must remain closed to modification 43
- 44.
- 45.
- 46.
- 47.
- 48. Strive for Loosely CoupledDesigns... • ...Between Objects That Interact • Allows you to build flexible OO systems that can handle change • interdependency is minimized • Changes to one object won’t affect another object • Objects can be used independently 48
- 49.
- 50. A Class ShouldHave... • ...Only One Reason to Change • Classes can inadvertently assume too many responsibilities • interdependency is minimized • cross-cutting concerns • Assign a responsibility to one class, and only one class 50
- 51. Local C++ User Groups •ACGNJ C++ Users Group • facilitated by Bruce Arnold • acgnj.barnold.us 51
- 52. Local Java UserGroups (1) • ACGNJ Java Users Group • facilitated by Mike Redlich • javasig.org • Princeton Java Users Group • facilitated byYakov Fain • meetup.com/NJFlex 52
- 53. Local Java UserGroups (2) • NYJavaSIG • facilitated by Frank Greco • javasig.com • PhillyJUG • facilitated by Martin Snyder, et. al. • meetup.com/PhillyJUG 53
- 54. Local Java UserGroups (3) • Capital District Java Developers Network • facilitated by Dan Patsey • cdjdn.com • currently restructuring 54
- 55.
- 56.
- 57. Upcoming Events • ACGNJJava Users Group • Dr. Venkat Subramaniam • Monday, March 19, 2018 • DorothyYoung Center for the Arts, Room 106 • Drew University • 7:30-9:00pm • “Twelve Ways to Make Code Suck Less” 57
- 58.
- 59. Upcoming Events • March17-18, 2017 •tcf-nj.org • April 18-19, 2017 •phillyemergingtech.com 59