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 =...
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...
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 ...
1class Book  attr_reader :title, :release_year  attr_accessor :price  def initialize(title, price,release_year)    @title ...
1class Book  attr_reader :title, :release_year  attr_accessor :price  def initialize(title, price,release_year)    @title ...
2
2class Book  attr_reader :title,:release_year  attr_accessor :price  def initialize(title, price,release_year)    @title =...
2class Book  attr_reader :title,:release_year  attr_accessor :price  def initialize(title, price,release_year)    @title =...
2class Book  attr_reader :title,:release_year  attr_accessor :price  def initialize(title, price,release_year)    @title =...
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_yea...
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
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Oopro with Ruby
Upcoming SlideShare
Loading in …5
×

Oopro with Ruby

862 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
862
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \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 &quot;machine&quot; with a distinct role or responsibility. The actions (or &quot;methods&quot;) on these objects are closely associated with the object. For example, OOP data structures tend to &quot;carry their own operators around with them&quot; (or at least &quot;inherit&quot; them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one &quot;long&quot; 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&apos;s data to be &apos;global&apos;, 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 &quot;class objects.&quot; 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 &quot;machine&quot; with a distinct role or responsibility. The actions (or &quot;methods&quot;) on these objects are closely associated with the object. For example, OOP data structures tend to &quot;carry their own operators around with them&quot; (or at least &quot;inherit&quot; them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one &quot;long&quot; 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&apos;s data to be &apos;global&apos;, 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 &quot;class objects.&quot; 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 &quot;machine&quot; with a distinct role or responsibility. The actions (or &quot;methods&quot;) on these objects are closely associated with the object. For example, OOP data structures tend to &quot;carry their own operators around with them&quot; (or at least &quot;inherit&quot; them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one &quot;long&quot; 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&apos;s data to be &apos;global&apos;, 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 &quot;class objects.&quot; 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 &quot;machine&quot; with a distinct role or responsibility. The actions (or &quot;methods&quot;) on these objects are closely associated with the object. For example, OOP data structures tend to &quot;carry their own operators around with them&quot; (or at least &quot;inherit&quot; them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one &quot;long&quot; 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&apos;s data to be &apos;global&apos;, 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 &quot;class objects.&quot; 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 &quot;machine&quot; with a distinct role or responsibility. The actions (or &quot;methods&quot;) on these objects are closely associated with the object. For example, OOP data structures tend to &quot;carry their own operators around with them&quot; (or at least &quot;inherit&quot; them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one &quot;long&quot; 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&apos;s data to be &apos;global&apos;, 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 &quot;class objects.&quot; 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 &quot;machine&quot; with a distinct role or responsibility. The actions (or &quot;methods&quot;) on these objects are closely associated with the object. For example, OOP data structures tend to &quot;carry their own operators around with them&quot; (or at least &quot;inherit&quot; them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one &quot;long&quot; 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&apos;s data to be &apos;global&apos;, 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 &quot;class objects.&quot; 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 &quot;machine&quot; with a distinct role or responsibility. The actions (or &quot;methods&quot;) on these objects are closely associated with the object. For example, OOP data structures tend to &quot;carry their own operators around with them&quot; (or at least &quot;inherit&quot; them from a similar object or class) - except when they have to be serialized.\nSimple, non-OOP programs may be one &quot;long&quot; 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&apos;s data to be &apos;global&apos;, 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 &quot;class objects.&quot; 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

    1. 1. OOProWith Ruby
    2. 2. Hi (¡hola)
    3. 3. Hi (¡hola)• I’m Hanneli
    4. 4. Hi (¡hola)• I’m Hanneli• @hannelita
    5. 5. Hi (¡hola)• I’m Hanneli• @hannelita• Software developer
    6. 6. Hi (¡hola)• I’m Hanneli• @hannelita• Software developer• Coffee Addicted
    7. 7. Hi (¡hola)• I’m Hanneli• @hannelita• Software developer• Coffee Addicted• I don’t speak Spanish
    8. 8. I work at Caelum   @hannelita
    9. 9. I work at Caelum   @hannelita
    10. 10. We are serious
    11. 11. We are serious (Sometimes)
    12. 12. Hard work, huh?
    13. 13. We are also teachers
    14. 14. Teacher?
    15. 15. Teacher?Teacher
    16. 16. Teacher?Teacher =
    17. 17. Teacher?Teacher =
    18. 18. WAIT!
    19. 19. Let’s talk about Ruby
    20. 20. rails new myproject
    21. 21. rails new myproject
    22. 22. rails new myproject
    23. 23. Let’s talk about Ruby
    24. 24. There’s a language behind Rails :)
    25. 25. Programming
    26. 26. Learn a new language
    27. 27. Learn a new language
    28. 28. GDD (a.k.a GoogleDriven Development)
    29. 29. Styles
    30. 30. THIS
    31. 31. Choose one :)
    32. 32. Object Oriented Programming (OOP)
    33. 33. About OOP
    34. 34. About OOPYes, he works at Caelum
    35. 35. What have you heard?
    36. 36. What have you heard?• OOP... bla bla bla• bla bla bla• bla bla....• bla bla bla bla bla
    37. 37. What did you think about the definitions?
    38. 38. What did you think about the definitions?• F** that’s boring
    39. 39. What did you think about the definitions?• F** that’s boring• I wanna sleep
    40. 40. What did you think about the definitions?• F** that’s boring• I wanna sleep• What the hell am I doing here?
    41. 41. Things you have learned from the definitions:
    42. 42. Things you have learned from the definitions: nil
    43. 43. What have you learned about OOP?
    44. 44. OO principle:encapsulation
    45. 45. class Bookend
    46. 46. class Book attr_accessor :title,:price, :release_yearend
    47. 47. rails_book = Book.newrails_book.price = 70.00rails_book.title = "Agile WebDevelopment with Rails"rails_book.release_year = 2011
    48. 48. def print_invoice(books) books.each do |book| puts "Title: #{title} - #{book.price} endend
    49. 49. What is the output?
    50. 50. def print_invoice(books) books.each do |book| book.title = “TROLOLOLOLOL” puts "Title: #{title} - #{book.price} endend
    51. 51. And now?
    52. 52. Where’s the problem?
    53. 53. class Book attr_accessor :title,:price, :release_yearend
    54. 54. class Book attr_accessor :title,:price, :release_yearend
    55. 55. THISattr_accessor
    56. 56. Do you usually change the title of a book?
    57. 57. (please say no)
    58. 58. No!
    59. 59. So...
    60. 60. attr_accessorattr_reader
    61. 61. attr_accessorattr_reader
    62. 62. class Book attr_reader :title attr_accessor :price, :release_yearend
    63. 63. You will not change title too often
    64. 64. ... and all books have titles
    65. 65. i
    66. 66. in
    67. 67. ini
    68. 68. init
    69. 69. i n i ti
    70. 70. i n i tia
    71. 71. i n i tia l
    72. 72. i n i tia li
    73. 73. i n i tia liz
    74. 74. i n i tia lize
    75. 75. At the moment, he’s a n00bLvl 1
    76. 76. class Book attr_reader :title, attr_accessor :price,:release_year def initialize(title) @title = tile endend
    77. 77. Lvl up!Lvl 10
    78. 78. Challenge
    79. 79. 1 • Does release_year change too often?2 • When you create a book, aren’t you supposed to set a price?
    80. 80. 1
    81. 81. 1class Book attr_reader :title, :release_year attr_accessor :price def initialize(title, price,release_year) @title = title @release_year = release_year endend
    82. 82. 1class Book attr_reader :title, :release_year attr_accessor :price def initialize(title, price,release_year) @title = title @release_year = release_year endend
    83. 83. 1class Book attr_reader :title, :release_year attr_accessor :price def initialize(title, price,release_year) @title = title @release_year = release_year endend
    84. 84. 2
    85. 85. 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
    86. 86. 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
    87. 87. 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
    88. 88. Lvl up!Lvl 100
    89. 89. class Cart attr_accessor :booksend
    90. 90. cart = cart.newcart.books << book1
    91. 91. cart = cart.newcart.books << book1cart.books << book2 << book3
    92. 92. Suddenly remembers toadd publishing_house to Book
    93. 93. Suggestions?
    94. 94. Open classes
    95. 95. Your code
    96. 96. Let’s see some problems
    97. 97. Looks better
    98. 98. All about encapsulation
    99. 99. class Book#attributes here def add_taxes if @release_year > 2010 @price = price*1.1 end endend
    100. 100. class Magazine#attributes here def add_taxes if @release_year > 2010 @price = price*1.2 end endend
    101. 101. Similar?
    102. 102. class Product attr_reader :title, :release_year attr_accessor :price def add_taxes(tax) if @release_year > 2010 @price = price*tax end endend
    103. 103. Inheritanceclass Book < Productend
    104. 104. And if we had a shipping_tax?
    105. 105. class Product #attributes here def shipping_tax(tax) #code here endend
    106. 106. #Win
    107. 107. #Win
    108. 108. class EBook#attributes here def add_taxes if @release_year > 2010 @price = price*1.1 end endend
    109. 109. Suggestions?
    110. 110. Inheritance?class EBook < Productend
    111. 111. Does EBook have shipping_tax?
    112. 112. Be careful about inheritance!
    113. 113. We can use modules
    114. 114. Next steps:Metaprogramming
    115. 115. Ruby has many features
    116. 116. If you choose aprogramming style, try to keep your code clean.
    117. 117. Thank you! ¡gracias Questions?hannelita@gmail.com.br Twitter: @hannelita http://caelum.com.br

    ×