• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Oopro with Ruby
 

Oopro with Ruby

on

  • 688 views

 

Statistics

Views

Total Views
688
Views on SlideShare
678
Embed Views
10

Actions

Likes
0
Downloads
6
Comments
0

3 Embeds 10

https://twitter.com 5
http://www.linkedin.com 4
http://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

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
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often group smaller sections of these statements into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects.\nIn contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries for retrieving or modifying the data they control. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. The practice of using subroutines to examine or modify certain kinds of data was also used in non-OOP modular programming, well before the widespread use of object-oriented programming.\n\n
  • An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often group smaller sections of these statements into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects.\nIn contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries for retrieving or modifying the data they control. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. The practice of using subroutines to examine or modify certain kinds of data was also used in non-OOP modular programming, well before the widespread use of object-oriented programming.\n\n
  • An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often group smaller sections of these statements into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects.\nIn contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries for retrieving or modifying the data they control. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. The practice of using subroutines to examine or modify certain kinds of data was also used in non-OOP modular programming, well before the widespread use of object-oriented programming.\n\n
  • An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often group smaller sections of these statements into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects.\nIn contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries for retrieving or modifying the data they control. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. The practice of using subroutines to examine or modify certain kinds of data was also used in non-OOP modular programming, well before the widespread use of object-oriented programming.\n\n
  • An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often group smaller sections of these statements into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects.\nIn contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries for retrieving or modifying the data they control. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. The practice of using subroutines to examine or modify certain kinds of data was also used in non-OOP modular programming, well before the widespread use of object-oriented programming.\n\n
  • An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often group smaller sections of these statements into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects.\nIn contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries for retrieving or modifying the data they control. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. The practice of using subroutines to examine or modify certain kinds of data was also used in non-OOP modular programming, well before the widespread use of object-oriented programming.\n\n
  • An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one "long" list of statements (or commands). More complex programs will often group smaller sections of these statements into functions or subroutines each of which might perform a particular task. With designs of this sort, it is common for some of the program's data to be 'global', i.e. accessible from any part of the program. As programs grow in size, allowing any function to modify any piece of data means that bugs can have wide-reaching effects.\nIn contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are either bundled in with the data or inherited from "class objects." These act as the intermediaries for retrieving or modifying the data they control. The programming construct that combines data with a set of methods for accessing and managing those data is called an object. The practice of using subroutines to examine or modify certain kinds of data was also used in non-OOP modular programming, well before the widespread use of object-oriented programming.\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Oopro with Ruby Oopro with Ruby Presentation Transcript

  • OOProWith Ruby
  • Hi (¡hola)
  • Hi (¡hola)• I’m Hanneli
  • Hi (¡hola)• I’m Hanneli• @hannelita
  • Hi (¡hola)• I’m Hanneli• @hannelita• Software developer
  • Hi (¡hola)• I’m Hanneli• @hannelita• Software developer• Coffee Addicted
  • Hi (¡hola)• I’m Hanneli• @hannelita• Software developer• Coffee Addicted• I don’t speak Spanish
  • I work at Caelum   @hannelita
  • I work at Caelum   @hannelita
  • We are serious
  • We are serious (Sometimes)
  • Hard work, huh?
  • We are also teachers
  • Teacher?
  • Teacher?Teacher
  • Teacher?Teacher =
  • Teacher?Teacher =
  • WAIT!
  • Let’s talk about Ruby
  • rails new myproject
  • rails new myproject
  • rails new myproject
  • Let’s talk about Ruby
  • There’s a language behind Rails :)
  • Programming
  • Learn a new language
  • Learn a new language
  • GDD (a.k.a GoogleDriven Development)
  • Styles
  • THIS
  • Choose one :)
  • Object Oriented Programming (OOP)
  • About OOP
  • About OOPYes, he works at Caelum
  • What have you heard?
  • What have you heard?• OOP... bla bla bla• bla bla bla• bla bla....• bla bla bla bla bla
  • What did you think about the definitions?
  • What did you think about the definitions?• F** that’s boring
  • What did you think about the definitions?• F** that’s boring• I wanna sleep
  • What did you think about the definitions?• F** that’s boring• I wanna sleep• What the hell am I doing here?
  • Things you have learned from the definitions:
  • Things you have learned from the definitions: nil
  • What have you learned about OOP?
  • OO principle:encapsulation
  • class Bookend
  • class Book attr_accessor :title,:price, :release_yearend
  • rails_book = Book.newrails_book.price = 70.00rails_book.title = "Agile WebDevelopment with Rails"rails_book.release_year = 2011
  • def print_invoice(books) books.each do |book| puts "Title: #{title} - #{book.price} endend
  • What is the output?
  • def print_invoice(books) books.each do |book| book.title = “TROLOLOLOLOL” puts "Title: #{title} - #{book.price} endend
  • And now?
  • Where’s the problem?
  • class Book attr_accessor :title,:price, :release_yearend
  • class Book attr_accessor :title,:price, :release_yearend
  • THISattr_accessor
  • Do you usually change the title of a book?
  • (please say no)
  • No!
  • So...
  • attr_accessorattr_reader
  • attr_accessorattr_reader
  • class Book attr_reader :title attr_accessor :price, :release_yearend
  • You will not change title too often
  • ... and all books have titles
  • i
  • in
  • ini
  • init
  • i n i ti
  • i n i tia
  • i n i tia l
  • i n i tia li
  • i n i tia liz
  • i n i tia lize
  • At the moment, he’s a n00bLvl 1
  • class Book attr_reader :title, attr_accessor :price,:release_year def initialize(title) @title = tile endend
  • Lvl up!Lvl 10
  • Challenge
  • 1 • Does release_year change too often?2 • When you create a book, aren’t you supposed to set a price?
  • 1
  • 1class Book attr_reader :title, :release_year attr_accessor :price def initialize(title, price,release_year) @title = title @release_year = release_year endend
  • 1class Book attr_reader :title, :release_year attr_accessor :price def initialize(title, price,release_year) @title = title @release_year = release_year endend
  • 1class Book attr_reader :title, :release_year attr_accessor :price def initialize(title, price,release_year) @title = title @release_year = release_year endend
  • 2
  • 2class Book attr_reader :title,:release_year attr_accessor :price def initialize(title, price,release_year) @title = title @price = price @release_year = release_year endend
  • 2class Book attr_reader :title,:release_year attr_accessor :price def initialize(title, price,release_year) @title = title @price = price @release_year = release_year endend
  • 2class Book attr_reader :title,:release_year attr_accessor :price def initialize(title, price,release_year) @title = title @price = price @release_year = release_year endend
  • Lvl up!Lvl 100
  • class Cart attr_accessor :booksend
  • cart = cart.newcart.books << book1
  • cart = cart.newcart.books << book1cart.books << book2 << book3
  • Suddenly remembers toadd publishing_house to Book
  • Suggestions?
  • Open classes
  • Your code
  • Let’s see some problems
  • Looks better
  • All about encapsulation
  • class Book#attributes here def add_taxes if @release_year > 2010 @price = price*1.1 end endend
  • class Magazine#attributes here def add_taxes if @release_year > 2010 @price = price*1.2 end endend
  • Similar?
  • class Product attr_reader :title, :release_year attr_accessor :price def add_taxes(tax) if @release_year > 2010 @price = price*tax end endend
  • Inheritanceclass Book < Productend
  • And if we had a shipping_tax?
  • class Product #attributes here def shipping_tax(tax) #code here endend
  • #Win
  • #Win
  • class EBook#attributes here def add_taxes if @release_year > 2010 @price = price*1.1 end endend
  • Suggestions?
  • Inheritance?class EBook < Productend
  • Does EBook have shipping_tax?
  • Be careful about inheritance!
  • We can use modules
  • Next steps:Metaprogramming
  • Ruby has many features
  • If you choose aprogramming style, try to keep your code clean.
  • Thank you! ¡gracias Questions?hannelita@gmail.com.br Twitter: @hannelita http://caelum.com.br