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, 2014 at 17:20
  • I think this might be a hint that the "local variable part" should rather be a method on its own. Sep 23, 2014 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, 2014 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, 2014 at 17:41
  • 1
    Why is this tagged python?
    – Weaver
    Sep 23, 2014 at 20:12

1 Answer 1


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, 2014 at 8:15
  • @embert glad I could help. :)
    – Crono
    Sep 25, 2014 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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