• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Lecture 4 Software Engineering and Design Brief Introduction to Programming
 

Lecture 4 Software Engineering and Design Brief Introduction to Programming

on

  • 1,637 views

3F6 Software Engineering and Design, January 2012, lecture slides 4, Brief Introduction to Programming Languages, Dr Elena Punskaya, Cambridge University Engineering Department

3F6 Software Engineering and Design, January 2012, lecture slides 4, Brief Introduction to Programming Languages, Dr Elena Punskaya, Cambridge University Engineering Department

Statistics

Views

Total Views
1,637
Views on SlideShare
1,256
Embed Views
381

Actions

Likes
1
Downloads
12
Comments
0

1 Embed 381

http://www-sigproc.eng.cam.ac.uk 381

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Lecture 4 Software Engineering and Design Brief Introduction to Programming Lecture 4 Software Engineering and Design Brief Introduction to Programming Presentation Transcript

    • OO Programming Languages Syntax Exceptions Handling Elena Punskaya, op205@cam.ac.uk 1
    • OO in Java //abstract class declaration• Abstract class defines public abstract class Account { shared implementation private int mAccountNumber; //constructor public Account(int accountNumber)• Methods declared Abstract { mAccountNumber = accountNumber; MUST be implemented by } // abstract method declaration subclasses public abstract void credit(Amount amount); }• Interface can only define //interface declaration method signatures public interface IVerifiable { (names, parameters, //declaring the interface method public boolean isVerified(); output) and no } implementation //PayPal derives from Account and realises IVerifiable public class PayPalAccount extends Account implements IVerifiable {• Classes can Extend other //constructor, calls the superclass public PayPalAccount(int accountNumber) classes and Implement { super(accountNumber); interfaces } //implementation of the abstract method public void credit(Amount amount)• By default, all class { //send money to PayPal methods can be overridden } //implementation of the interface method (extended/implemented) public boolean isVerified() { in the subclasses //do check and return result } } © 2012 Elena Punskaya 2 Cambridge University Engineering Department 2
    • OO in C# //abstract class declaration• Very similar to Java public abstract class Account { syntax and concepts, but private int mAccountNumber; //constructor also some differences public Account(int accountNumber) { mAccountNumber = accountNumber;• Any non-abstract class } // abstract method declaration methods have to be public abstract void credit(Amount amount); explicitly declared virtual } so can be overridden //interface declaration public interface IVerifiable (extended/implemented) { //declaring the interface method in the subclasses } public boolean isVerified(); • C# vs Java comparison: //PayPal derives from Account and realises IVerifiable public class PayPalAccount extends :Account, implements IVerifiable { - http://msdn.microsoft.com/en-us/ //constructor, calls the superclass library/ms836794.aspx public PayPalAccount(int accountNumber) : base(accountNumber) { super(accountNumber); } //implementation of the abstract method public void credit(Amount amount) { //send money to PayPal } //implementation of the interface method public boolean isVerified() { //do check and return result } } © 2012 Elena Punskaya 3 Cambridge University Engineering Department 3
    • OO in C++ //class declaration• Methods need to be class Account { declared virtual to be //declaring all publicly accessible methods/attributes public: extended (as in C#) //constructor Account(int accountNumber) {• Pure virtual methods mAccountNumber = accountNumber; } (ending declarations with // abstract method declaration “=0”) are equivalent to virtual void credit(Amount amount) = 0; abstract methods in Java private: int mAccountNumber; };• No dedicated concept of //interface (equivalent) declaration Interfaces, but same class IVerifiable { effect is achieved by //pure virtual (abstract) method declaration public: defining a class that } virtual bool isVerified() = 0; contains pure virtual //PayPal derives from Account and IVerifiable methods only public class PayPalAccount : public Account, public IVerifiable { public:• C++ and Java differences //constructor, calls the superclass PayPalAccount(int accountNumber):Account(accountNumber) - http://www.cprogramming.com/ { } tutorial/java/syntax-differences- //declaring the implementation java-c++.html virtual void credit(Amount amount); //declaring the implementation virtual bool isVerified(); } © 2012 Elena Punskaya 4 Cambridge University Engineering Department 4
    • Error Handling• All software encounters error conditions during // add error reporting to code that can fail operations public int doSomethingRisky() {• Good software will <..> if (problemNumber1Happened) manage error situations return 1; gracefully and robustly else if (problemNumber2Happened) return 2; else• Error handling has to be return 0; //all good implemented in the code } //using this method, need to build in checks• A standard option from int result = riskyAction.doSomethingRisky(); procedural languages – if (result == 0) { Error Codes //All good, can proceed }• Main idea: else if(result == 1) { - use a code to indicate some //handle Problem1 } specific error else if(result == 2) - make the function to return a { code //handle Problem2 } - check the return code if it is OK or error © 2012 Elena Punskaya 5 Cambridge University Engineering Department 5
    • Exceptions• Errors such as the above represent exceptions to the // add error reporting to code that can fail normal program flow. public void doSomethingRisky() {• Handling exceptions via return <..> if (problemNumber1Happened) codes has a number of //throw forces us to exit the current disadvantages: //method and returns an exception object throw problemNumber1Exception; - Extra code needs to be inserted in each else if (problemNumber2Happened) function to pass the errors back. throw problemNumber2Exception; } - If one function fails to check for errors and pass them back, the errors will not get //using this method, wrap it in try/catch block handled //to catch returned exceptions try - The extra error checking obscures the main { function of the code, making it difficult to riskyAction.doSomethingRisky(); } understand catch (ProblemNumber1Exception error) - Error recovery code becomes intertwined { with the normal operation code //handle Problem1 } - Functions cannot use return values for catch (ProblemNumber2Exception error) normal purposes { //handle Problem2• There is another way... }• Exceptions! © 2012 Elena Punskaya 6 Cambridge University Engineering Department 6
    • Exceptions• C++ example //C++ class to define Exceptions class TradingErr { TradingErr (ErrType ee, Time tt) {e=ee; t=tt;}• Using exceptions, the code is ErrType e; Time t; easier to follow because the }; //main program method error handling parts are int main() { try { clearly separated from the <..> regular program flow //MyTrader() can re-throw an exception MyTrader(); <..>• An exception handler can //Exception handling throw the exception again } catch (TradingError x) { ReportError(x.e, x.t); allowing some errors to be } } trapped and repaired and //------------------------------------------------ others to be propagated, e.g. void MyTrader() { <..> from TE_GetPrice() to //code that can re-throw an exception MyTrader() to the main float price = TE_GetPrice(day); <..> method, where it is handled } //------------------------------------------------• Exceptions should REALLY be float TE_GetPrice(int day) { <..> exceptional and not be a part //code that can throw an exception if (!Valid(day)) of normal program flow throw TradingErr(BAD_DAY,TimeNow()); <..> } © 2012 Elena Punskaya 7 Cambridge University Engineering Department 7
    • No Code Wars! – Tools for the Job• Debating comparative advantages and disadvantages of programming languages makes a good (if often heated) conversation, but in reality the choice of the language is often dictated by the application!• For example, in mobile application development: - Android, Blackberry, J2ME: Java - iPhone: Objective-C - Windows Phone: C# - Symbian (RIP): C++• Being proficient in a range of languages helps Source: http://www.rackspace.com/cloud/blog/2011/05/17/infographic-evolution-of- computer-languages/ © 2012 Elena Punskaya 8 Cambridge University Engineering Department 8