1 / 27

CSCE 240 – Intro to Software Engineering

CSCE 240 – Intro to Software Engineering . Lecture 3. Quote of the Day. “Politics is war without bloodshed while war is politics with bloodshed.” -Mao Tse-tung. Overview. Finish Chapter 2 More about classes/objects Polymorphism Inheritance Important 0-0 Concepts

genevak
Download Presentation

CSCE 240 – Intro to Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CSCE 240 – Intro to Software Engineering Lecture 3

  2. Quote of the Day “Politics is war without bloodshed while war is politics with bloodshed.” -Mao Tse-tung

  3. Overview • Finish Chapter 2 • More about classes/objects • Polymorphism • Inheritance • Important 0-0 Concepts • Homework 1 (due Monday, June 9th)

  4. Instance Varibles • Attribute – “a simple piece of data used to represent the properties of an object.” – variables declared inside a class • Association – “the relationship between instances of one class and instances of another.” – lots more of this when we get into UML (Person has Supervisor)

  5. Polymorphism Definition – “a property of O-O software by which an abstract operation may be performed in different ways, typically in different classes.” (see next slide)

  6. Polymorphism (continued)

  7. Inheritance “If several classes have attributes, associations or operations in common, it is best to avoid duplication by creating a separate class that contains these common aspects.” It can also be used to break up complex classes into more manageable classes.

  8. Inheritance (continued) • Generalization – a two level hierarchy with one super class and an number of subclasses. • Inheritance Hierarchy – has more than two levels. Sometimes called an isa hierarchy.

  9. Inheritance (continued) Definition – “the implicit possession by a subclass of features defined in a superclass. Features include variables [attributes] and methods.”

  10. Checks for good generalization • If subclass or superclass have ambiguous names(bus instead of NightlyBusRoute) • If subclass doesn’t remain distinctive throughout lifetime (ex. OverdrawnAccount as a subclass of account – an account won’t always remain overdrawn) • Inherited features make sense.

  11. Inheritance terms • Leaf Class – classes at bottom level of inheritance hierarchy (may not be abstract, must be concrete) • Abstract Class – can never have any instances (shown in italics) • Concrete Class – can have instances

  12. More Inheritance Terms • Abstract Operation – no method exists for operation exists in class, but is logical for class to have it. Any class with an abstract operation is ALWAYS and abstract class. • Overriding – a method in a class replaces a method it inherited from a superclass.

  13. Reasons to Override • Restriction – to prevent a violation of a constraint present in subclass but not in the superclass. • Extension – to add a new feature (capability) to an inherited method. • Optimization – overriding method has same effect as inherited method, only does it more efficiently.

  14. From Textbook

  15. A few more Inheritance Terms • Immutable Object – an object where no operation may change the variables of an instance. If an operation would change these variables, then it must create a totally new object with the new values. Variables are only set when object is first created.

  16. Dynamic Binding Definition – program decides what method to run ‘on the fly’. Procedure for Dynamic Binding • Check for concrete method in current class. If found, use, otherwise, • Check immediate superclass for concrete method, if found run. Otherwise repeat 2 until concrete method found. If none found, return error.

  17. What make a language Object Oriented • Identity – programmer can refer to an object without referring to instance variables contained within. All objects are unique. Objects with same variables are still recognized as different objects. • Classes – must be able to organize code into classes, which describe the structure and function of a set of objects.

  18. WMaLOO (continued) • Inheritance – classes must be able to be organized into inheritance hierarchies where class features inherit from superclasses to subclasses. • Polymorphism – methods in related classes can have the same name and implement the same abstract operation. Must allow dynamic binding and overloading.

  19. Other OO Concepts • Abstraction • Object -> something in the world • Class -> objects • Superclass -> subclasses • Operation -> methods • Attributes and associations -> instance variables • Modularity • Code can be constructed entirely of classes • Encapsulation • Details can be hidden in classes • This gives rise to information hiding: • Programmers do not need to know all the details of a class (from authors slide)

  20. Risks in Programming language choice and O-O programming • Language Evolution – programming languages change, and some of these changes will make programs developed with older versions either not function or have unforeseen results. • Efficiency concerns – java being a language usually run using a virtual machine tends to make it less efficiently than C++. Lots of dynamic binding or object allocation also hurts efficiency.

  21. The next few slides are from the authors slides. These discuss useful program style guidelines.

  22. Programming Style Guidelines • Remember that programs are for people to read • Always choose the simpler alternative • Reject clever code that is hard to understand • Shorter code is not necessarily better • Choose good names • Make them highly descriptive • Do not worry about using long names

  23. Programming style … • Comment extensively • Comment whatever is non-obvious • Do not comment the obvious • Comments should be 25-50% of the code • Organize class elements consistently • Variables, constructors, public methods then private methods • Be consistent regarding layout of code

  24. Programming style … • Avoid duplication of code • Do not ‘clone’ if possible [cut and pasting] • Create a new method and call it • Cloning results in two copies that may both have bugs • When one copy of the bug is fixed, the other may be forgotten

  25. Programming style ... • Adhere to good object oriented principles • E.g. the ‘isa rule’ • Prefer private as opposed to public • Do not mix user interface code with non-user interface code • Interact with the user in separate classes • This makes non-UI classes more reusable (end author slides)

  26. For Next time • Read Chapter 5, 5.1-5.4 • UML Class diagrams

  27. Homework 1 Due Monday, June 9th Chapter 1 – E1.1, E1.2, E1.3 Chapter 2 – E2.1, E2.8, E2.10 a, f, E2.17

More Related