This is a lecture memo of the special lecture on multi-scale simulation. The index of lecture memos is here
The reference material this time is Chart type ruby-VI (hello class).
Reference article is here
class
This time we will learn about class. As a key point of the idea of object thinking
--capsulation --inheritance --Polymorphism
There are three, but method and class seem to belong to the first concealment.
hello class
Learn about class using the previously created hello.rb.
def puts_hello name
puts "Hello #{name}."
end
def gets_name
name = ARGV[0] || 'world'
return name
end
name = gets_name
puts_hello name
It is soulful to use class to eliminate the main function itself.
First, create a Hello class.
class Hello
def puts_hello name
puts "Hello #{name}."
end
def gets_name
name = ARGV[0] || 'world'
return name
end
end
Hello.new
Hello.new is called an instance, and nothing happens with this alone.
Here, implement a program equivalent to hello.rb by using a method called initialize that is executed when an instance is created.
class Hello
def initialize
name = gets_name
puts_hello name
end
def puts_hello name
puts "Hello #{name}."
end
def gets_name
name = ARGV[0] || 'world'
return name
end
end
Hello.new
It's getting more stylish little by little. The question here is whether it should be passed as an argument to the variable name of the initialize method, or should it be called in the function puts \ _hello.
This is where class-specific instance variables come into play. By setting @ name, it can be treated as a variable that can be shared in instance as long as the object exists. (The nuance feels like a global variable, isn't it?)
Using the instance variable, it looks like this.
class Hello
def initialize
@name = gets_name
puts_hello
end
def puts_hello name
puts "Hello #{@name}."
end
def gets_name
name = ARGV[0] || 'world'
return name
end
end
Hello.new
When I run it,
> ruby hello_class.rb
Hello world.
> ruby hello_class.rb Rudy
Hello Rudy.
I was able to create a program that can obtain the output of hello.rb using class.
I have never been aware of the difference between method and object orientation, so I will take this opportunity to learn.
--object oriented: subject.verb (object)
Certainly object-oriented is the latter image.
A method-like image looks like function name (necessary variable), but in object-oriented programming, it looks like target variable.function name (necessary thing). Is it from such an image that it is easier to understand which variable the object-oriented is working on?
For the time being, let's look at three ways of writing method, class inheritance, and override according to the lecture materials.
require 'colorize'
# method
def hello(name)
"Hello #{name}."
end
# inherited class
class Greeter < String
def hello
"Hello #{self}."
end
end
# extend class
class String
def hello
"Hello #{self}."
end
end
# method call
name = ARGV[0]
puts hello(name).green
# inherited class call
greeter = Greeter.new(ARGV[0])
puts greeter.hello.green
# extend class call, override
puts ARGV[0].hello.green
It is good to compare the method and class parts, but the point to pay attention to is the calling part. The method of method assigns to a variable as usual and receives it as an argument.
What about inheriting class? The instance is created once, and the value is held at that time. it's beautiful.
In override, even an instance is not created in the first place. In the first place, the process is placed in the String class. Stylish in a sense.
Which one is better is definitely override. Does it depend on people's tastes?
attr_accessor
I read the reference article, but I didn't understand it.
** Insufficient ability. No disappointment. ** **
** Classify assert \ _equal and override it to Integer. ** **
- 3.assert_True will be returned with equal 3.
-3 should be returned by self.
-It seems better to include the module. .. .. I'm not confident.
I tried it because it looks interesting.
require 'colorize'
class Integer
def puts_vals(expected, result)
puts "expected :: #{expected}"
puts "result :: #{result}"
end
def assert_equal(expected)
puts_vals(expected, self)
print case expected == self
when true ; "succeeded in #{__method__}.\n".green
when false ; "failed in #{__method__}.\n".red
end
end
end
puts 3.assert_equal 3
> ruby assert_equal_class.rb
expected :: 3
result :: 3
succeeded in assert_equal.
It looks like it's done. This time, I feel that I understand a little about the goodness of object orientation.
This time, only chart type Ruby is available.
Next lecture
-Chart type ruby-appendix-VI (thor, rubocop)
That's right.