What would be the best variable usage in Ruby?












1















I am encountering few doubts regarding the best approach to use classes and scoped variables in Ruby.
While saving information in a file, using a specific class in order to do it, I would personally store the concerned data in a class variable during the instantiation, instead of instantiating and calling another function directly with the params.



Since I am not really clear, here are the two points I am talking about :



# from another class, could be called with the following syntax : 
# className.new('some params').create

def initialize(params)

@params = params
end

def create

File.open 'data.csv', 'a+' do |file|
file.write @params
end
end

# usage : className.new('some params').create


The other possible method would be to only instantiate the class, and passing all the params by calling the create function.



def initialize
end

def create(params)

File.open 'data.csv', 'a+' do |file|
file.write params
end
end

# usage :
class_instance = className.new
class_instance.create 'some params'


From your point of view, which method should be definitively used ? Is there a lack of performance in a case ? What are the risks about using one or another method ?










share|improve this question


















  • 1





    The latter is better, plus the create method should be a class method (static.)

    – Aleksei Matiushkin
    Nov 15 '18 at 9:43











  • Could you please argument why the latter is better ?

    – Atille
    Nov 15 '18 at 9:46






  • 1





    It does not produce a garbage instance variable :) Also, it’s always better to keep parameters as near to their usage as possible.

    – Aleksei Matiushkin
    Nov 15 '18 at 9:47













  • Is this true in a case of multi calls ? I mean using the create(params), then a mail(params) function, from the same class ? I would have to update two or more information from my script to make it correct, instead of simply updating my initialize() function.

    – Atille
    Nov 15 '18 at 9:55













  • If multiple calls are all have the same params, there is a design flaw. If params differ from call to call then the former approach just won’t work. And let me repeat it in bold, make the method static to avoid class instantiation at all.

    – Aleksei Matiushkin
    Nov 15 '18 at 9:57


















1















I am encountering few doubts regarding the best approach to use classes and scoped variables in Ruby.
While saving information in a file, using a specific class in order to do it, I would personally store the concerned data in a class variable during the instantiation, instead of instantiating and calling another function directly with the params.



Since I am not really clear, here are the two points I am talking about :



# from another class, could be called with the following syntax : 
# className.new('some params').create

def initialize(params)

@params = params
end

def create

File.open 'data.csv', 'a+' do |file|
file.write @params
end
end

# usage : className.new('some params').create


The other possible method would be to only instantiate the class, and passing all the params by calling the create function.



def initialize
end

def create(params)

File.open 'data.csv', 'a+' do |file|
file.write params
end
end

# usage :
class_instance = className.new
class_instance.create 'some params'


From your point of view, which method should be definitively used ? Is there a lack of performance in a case ? What are the risks about using one or another method ?










share|improve this question


















  • 1





    The latter is better, plus the create method should be a class method (static.)

    – Aleksei Matiushkin
    Nov 15 '18 at 9:43











  • Could you please argument why the latter is better ?

    – Atille
    Nov 15 '18 at 9:46






  • 1





    It does not produce a garbage instance variable :) Also, it’s always better to keep parameters as near to their usage as possible.

    – Aleksei Matiushkin
    Nov 15 '18 at 9:47













  • Is this true in a case of multi calls ? I mean using the create(params), then a mail(params) function, from the same class ? I would have to update two or more information from my script to make it correct, instead of simply updating my initialize() function.

    – Atille
    Nov 15 '18 at 9:55













  • If multiple calls are all have the same params, there is a design flaw. If params differ from call to call then the former approach just won’t work. And let me repeat it in bold, make the method static to avoid class instantiation at all.

    – Aleksei Matiushkin
    Nov 15 '18 at 9:57
















1












1








1








I am encountering few doubts regarding the best approach to use classes and scoped variables in Ruby.
While saving information in a file, using a specific class in order to do it, I would personally store the concerned data in a class variable during the instantiation, instead of instantiating and calling another function directly with the params.



Since I am not really clear, here are the two points I am talking about :



# from another class, could be called with the following syntax : 
# className.new('some params').create

def initialize(params)

@params = params
end

def create

File.open 'data.csv', 'a+' do |file|
file.write @params
end
end

# usage : className.new('some params').create


The other possible method would be to only instantiate the class, and passing all the params by calling the create function.



def initialize
end

def create(params)

File.open 'data.csv', 'a+' do |file|
file.write params
end
end

# usage :
class_instance = className.new
class_instance.create 'some params'


From your point of view, which method should be definitively used ? Is there a lack of performance in a case ? What are the risks about using one or another method ?










share|improve this question














I am encountering few doubts regarding the best approach to use classes and scoped variables in Ruby.
While saving information in a file, using a specific class in order to do it, I would personally store the concerned data in a class variable during the instantiation, instead of instantiating and calling another function directly with the params.



Since I am not really clear, here are the two points I am talking about :



# from another class, could be called with the following syntax : 
# className.new('some params').create

def initialize(params)

@params = params
end

def create

File.open 'data.csv', 'a+' do |file|
file.write @params
end
end

# usage : className.new('some params').create


The other possible method would be to only instantiate the class, and passing all the params by calling the create function.



def initialize
end

def create(params)

File.open 'data.csv', 'a+' do |file|
file.write params
end
end

# usage :
class_instance = className.new
class_instance.create 'some params'


From your point of view, which method should be definitively used ? Is there a lack of performance in a case ? What are the risks about using one or another method ?







ruby class variables






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 15 '18 at 9:33









AtilleAtille

312




312








  • 1





    The latter is better, plus the create method should be a class method (static.)

    – Aleksei Matiushkin
    Nov 15 '18 at 9:43











  • Could you please argument why the latter is better ?

    – Atille
    Nov 15 '18 at 9:46






  • 1





    It does not produce a garbage instance variable :) Also, it’s always better to keep parameters as near to their usage as possible.

    – Aleksei Matiushkin
    Nov 15 '18 at 9:47













  • Is this true in a case of multi calls ? I mean using the create(params), then a mail(params) function, from the same class ? I would have to update two or more information from my script to make it correct, instead of simply updating my initialize() function.

    – Atille
    Nov 15 '18 at 9:55













  • If multiple calls are all have the same params, there is a design flaw. If params differ from call to call then the former approach just won’t work. And let me repeat it in bold, make the method static to avoid class instantiation at all.

    – Aleksei Matiushkin
    Nov 15 '18 at 9:57
















  • 1





    The latter is better, plus the create method should be a class method (static.)

    – Aleksei Matiushkin
    Nov 15 '18 at 9:43











  • Could you please argument why the latter is better ?

    – Atille
    Nov 15 '18 at 9:46






  • 1





    It does not produce a garbage instance variable :) Also, it’s always better to keep parameters as near to their usage as possible.

    – Aleksei Matiushkin
    Nov 15 '18 at 9:47













  • Is this true in a case of multi calls ? I mean using the create(params), then a mail(params) function, from the same class ? I would have to update two or more information from my script to make it correct, instead of simply updating my initialize() function.

    – Atille
    Nov 15 '18 at 9:55













  • If multiple calls are all have the same params, there is a design flaw. If params differ from call to call then the former approach just won’t work. And let me repeat it in bold, make the method static to avoid class instantiation at all.

    – Aleksei Matiushkin
    Nov 15 '18 at 9:57










1




1





The latter is better, plus the create method should be a class method (static.)

– Aleksei Matiushkin
Nov 15 '18 at 9:43





The latter is better, plus the create method should be a class method (static.)

– Aleksei Matiushkin
Nov 15 '18 at 9:43













Could you please argument why the latter is better ?

– Atille
Nov 15 '18 at 9:46





Could you please argument why the latter is better ?

– Atille
Nov 15 '18 at 9:46




1




1





It does not produce a garbage instance variable :) Also, it’s always better to keep parameters as near to their usage as possible.

– Aleksei Matiushkin
Nov 15 '18 at 9:47







It does not produce a garbage instance variable :) Also, it’s always better to keep parameters as near to their usage as possible.

– Aleksei Matiushkin
Nov 15 '18 at 9:47















Is this true in a case of multi calls ? I mean using the create(params), then a mail(params) function, from the same class ? I would have to update two or more information from my script to make it correct, instead of simply updating my initialize() function.

– Atille
Nov 15 '18 at 9:55







Is this true in a case of multi calls ? I mean using the create(params), then a mail(params) function, from the same class ? I would have to update two or more information from my script to make it correct, instead of simply updating my initialize() function.

– Atille
Nov 15 '18 at 9:55















If multiple calls are all have the same params, there is a design flaw. If params differ from call to call then the former approach just won’t work. And let me repeat it in bold, make the method static to avoid class instantiation at all.

– Aleksei Matiushkin
Nov 15 '18 at 9:57







If multiple calls are all have the same params, there is a design flaw. If params differ from call to call then the former approach just won’t work. And let me repeat it in bold, make the method static to avoid class instantiation at all.

– Aleksei Matiushkin
Nov 15 '18 at 9:57














0






active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53316315%2fwhat-would-be-the-best-variable-usage-in-ruby%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53316315%2fwhat-would-be-the-best-variable-usage-in-ruby%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Bressuire

Vorschmack

Quarantine