A common problem for me - and it's not really a problem, but somehow I again and again ask myself, what is the normal way to handle this - is that there is a method and within this method a couple of variables are created, used and finally are supposed to be retained as instance variables.

Somehow I want to avoid dot notation, so I prefer variables to be local in a method instead accessing instance variables. Indeed only sometimes access time really matters cause the difference is not so big, but also when there are several variables with already longish descriptive names, if all these are referenced with obj. or self. it makes everything even longer and things become IMO less readable. This is why I tend to do have everything local and in the end of the method "save" it as instance variable. For instance

classdef myclass < handle

        function obj = myclass()
        function output = verifyBloodPressures(obj, p)
            basal_blood_pressures = getBloodPressures('basal', p);
            n = numel(basal_blood_pressures);
            output = zeros(n);

            for ii = 1:n
                basal_blood_pressures(ii) = basal_blood_pressures(ii) ...
                output(ii) = ...
            % Attach all variables to instance here 
            % instead of doing it right in the beginning
            obj.basal_blood_pressures = basal_blood_pressures;

But doing this attachment in the end also does not "feel right" somehow. Any advice on this? Is there any good way how to proceed here?

  • 2
    It doesn't feel right because calling the method ultimately changes the instance's state without much clues that it does. Why is your method even part of your class? Wouldn't it be better to separate your concerns? Like having a class that holds values created by a method in another class? – Crono Sep 23 '14 at 17:20
  • I think this might be a hint that the "local variable part" should rather be a method on its own. – Michael Osl Sep 23 '14 at 17:32
  • @crono Maybe. This is why I ask. calling the method ultimately changes the instance's state without much clues that it does - so, a method should not change the state of the instance unless is visible "from outside"? Yes, maybe what I miss is another class for the actual output – embert Sep 23 '14 at 17:36
  • @moeso the "local variable part" should rather be a method on its own - I didn't get you. Do you mean the "local variable part" should be encapsulated in another method, which does the processing. Is it about the hierachy / modularization somehow? – embert Sep 23 '14 at 17:41
  • 1
    Why is this tagged python? – StarWeaver Sep 23 '14 at 20:12

It's hard to answer this question since sometimes it does indeed make sense for a method to change an object's state. However, based on your sample code, I'd say that you might want to look into having your code splitted in two different classes.

One would be BloodPressureCalculator and hold your method. The latter should return an instance of the other class (let's call it BloodPressureData) that holds the different values your method produces.

These should probably be readonly too, as it's likely that messing around with blood pressure results wouldn't make sense.

  • Probably, as you pointed out, I have to think about the structure of the program rather than about the inner method structure. Usually I miss to zoom out like that, so - good hint. – embert Sep 25 '14 at 8:15
  • @embert glad I could help. :) – Crono Sep 25 '14 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.