Object-Oriented Variables – What is Internal State and Difference Between State and Internal State

definitionobject-orientedstatevariables

Ok, this question has been asked before, but it's still not clear to me. What exactly is internal state?

So far state is clear to me:
Functions contain behavior, variables have state, values don't. So state typically means the current value or data something like variables contain, simply said, if I'm right. By changing their values, you change their state (if this isn't correct, let me know :)).

But internal state is not very clear to me, it almost seems to me people are mixing up classes and objects: https://stackoverflow.com/questions/21345975/what-is-internal-state

And this definition isn't 100% clear te me either: http://www.cs.nmsu.edu/~rth/cs/cs177/map/intstate.html

So Objects contain internal state, am I right? So the object's state is actually the internal state? So If I have a class:

class Foo { 
    public $aMemberVar = 'aMemberVar Member Variable'; 
    public $aFuncName = 'aMemberFunc'; 


    function aMemberFunc() { 
        print 'Inside `aMemberFunc()`'; 
    } 
}

And I create an object:

$foo = new Foo;

The objects internal state consists of the values $aMemberVar and $aFuncName ?? And the internal state can change, for example by changing:

$foo->aMemberVar = 'new value';

But to be clear, the internal state includes private variables as well? You cannot change them, but they are part of the internal state?

Do I understand this correctly or do I misunderstand something? I'm quite confused cause why should you name it internal state if it's typically just state…

Best Answer

Internal state mainly makes sense as a term to differentiate from externally visible (and possibly directly modifiable) state.

Otherwise state is state. Don't worry about saying internal unless you need to differentiate from external. If you just say "state", it implies all state information unless you make it more specific through context.

Linux has a lot of internal state that it does not share with users. But you can see some external representation of state in tools like top or ps. Trying for a useful analogy.

Yes private members (variables, properties depends on the language) are part of state, as long as the object exists. They are internal, of course.

There's a whole other way to use the term external state, to represent the state of the environment in which the object or system exists. Some people use it this way. Other people just mean object state that is public.

Related Solutions

OOP Design Patterns – Object-to-Object Communication Explained

There is no hard and fast rule which methods an object must have.

Something is an object if you can talk about it as an entity with a name that is familiar to domain experts in either your problem domain or the solution domain. In essence, if you have a related set of properties and behaviors that you can refer to by a single name, then that set of properties and behaviors is an object.

The behaviors that I refer to fall into two broad categories:

Requests to take an action. The classic example of Dog::bark() falls in this category.
Requests for information. Most getter functions fall in this category.

There is nothing wrong with an object that has mostly (or only) getters. Some objects in some domains are just model an entity that must exist but that does not have any active behavior. Your User class might be one of those.

A class X with mostly getters becomes a code smell when

each getter also has a setter to change the property, and
either class X has invariants (invalid combinations of property values) that can be broken if you use the setters 'wrongly', or
class Y is performing operations on the properties of X that would logically fall within the responsibility of X.

An example of the first class with a code smell would be a class like this:

class Square {
    int x1, x2, y1, y2;
public:
    void SetTopLeft(int x, int y);
    void SetBottomRight(int x, int y);
};

Allowing to change the top-left and bottom-right coordinates independently makes it very easy to break the invariant that all sides of a square must have the same length and all corners are square.

An example of the second form of the code smell is a Dog class where the client moves a Tail object to make the dog wag its tail.

Python OOP – One Boilerplate Class vs Many Similar Classes

100+ almost identical classes is crazy. Classes are organizational structures. Having dozens of them with almost no variation does't seem useful. It's over-specialization.

It sounds very much like you need a single class with a shared lookup-table that defines the shared info. Something like:

from collections import namedtuple

Lang = namedtuple('Lang', 'style points creator')

LANG_FORM = {
    'Python': Lang('dynamic', 84, 'Guido van Rossum'),
    'Java':   Lang('static', 65, 'James Gosling'),
    # ...
    'Pascal': Lang('static', 33, 'Niklaus Wirth')
}

class Protean(object):

    def __init__(self, name, form):
        self.name = name
        self.form = form
        self.lang = LANG_FORM[form] # optional

    # methods here

Here LANG_FORM can be a global variable (quasi-constant), or it could be a class variable. Either way, each instance gets basically just a pointer back to its shared info (what you refer to as class variables). It doesn't even strictly need that, if you're willing to index LANG_FORM whenever you need it, rather than memorizing it in each instance.

If you want to have each of the instances depict itself based on its form/kind/quasi-class, add a __repr__ method:

def __repr__(self):
    classname = self.__class__.__name__
    return "{0}-{1}({2!r}, {3})".format(classname, self.form, self.name, self.lang.points)

Then:

p = Protean('CPython', 'Python')

print p

Yields:

Protean-Python('CPython', 84)

Best Answer

Related Solutions

OOP Design Patterns – Object-to-Object Communication Explained

Python OOP – One Boilerplate Class vs Many Similar Classes

Related Topic