Definition of static property of object in OOP

Question

Grady Booch in Object-Oriented Analysis and Design with Applications says:

The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties ...

Then:

Another property of a vending machine is that it can accept money. This is a static (i.e., fixed) property, meaning that it is an essential characteristic of a vending machine.

Then:

All properties have some value. This value might be a simple quantity, or it might denote another object.

I am in doubt in about "the ability of accepting money" is a real property. Instead it seems it describes a behavior. Also Grady Booch says "All properties have some value."; but what is the value of "the ability of accepting money"?

Note:

Before asking this question, I read these questions; but those did not give me any idea:

The use of the word "static" here is confusing because it has a different meaning in OOP. — Pieter B, Aug 24 '21 at 10:31
@PieterB: in several OO programming languages, but not in "OOP in general". — Doc Brown, Aug 24 '21 at 10:58

Flater · Accepted Answer · 2021-08-24T10:10:09.597

The explanations you quoted make sense from a semantical English point of view, but they are horribly ambiguous because it uses words that have very specific meaning in software development terms, but he's relying on the common English definition of these words.

This book was released 31 years ago and I suspect that it was ahead of what is now considered common OOP jargon, so the correctness of its words has changed because the world changed, not the book itself.

This book was revised 13 years later, and I suspect they may have modernized parts of the semantics (e.g. your third quote), but inconsistently so (e.g. not the first and second quote).

1

The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties

I believe he's talking about strong typing here, i.e. the fact that an object has a given type, which has a predetermined structure (i.e. an explicit class definition with methods, properties, ...) and that this structure is defined during design time (i.e. pre-compilation) but that the values stored inside are usually not known at design time, only during runtime.

What I suspect he is not talking about, but totally seems like he is at first sight, is static vs non-static properties.

If my interpretation is correct, then "state" here is not intended to mean "stored information" (as in: state vs behavior), but rather "structure of the class" (as in e.g.: the state of the union).

2

Another property of a vending machine is that it can accept money. This is a static (i.e., fixed) property, meaning that it is an essential characteristic of a vending machine.

The same trend of using semantical English continues here.

By "static", just like before, he seems to mean "part of the class definition", not static specifically.

By "property", it seems he means the common English word for "trait" or "characteristic", e.g. in the sentence "Each of these states of matter is characterized by different physical properties".

In more modern language, we would now say that accepting money is part of the contract of a vending machine.

This quote is not trying to distinguish properties from methods. It's saying that the ability to accept money needs to be part of a vending machine's public interface. The quote leaves it unspecified as to how this should be added to the class, but I do agree with you that this is obviously a method, not a class property.

3

All properties have some value. This value might be a simple quantity, or it might denote another object.

And then here, it seems like we've suddenly switched to using specific developer jargon. If you forget the earlier quotes, this statement makes perfect sense, essentially explaining that state is stored in class properties (whether static or not).

This is pretty much spot on, I think, especially the two different meanings of the word "property" in (1) & (2) vs (3). I just wanted to point out that even in the modern standard jargon, when we say "state" we don't *just* mean "stored information" (which is ideally invisible from the outside), we implicitly mean one of the possible combination of values that the member fields (and the constraints we put in) allow for (==> encoding one of the possible states). So we can talk about object behaving one way in this state, and the other way in that state, or about the state being invalid, etc. — Filip Milovanović, Aug 24 '21 at 21:31
@FilipMilovanović In semantical English, I'd say that your explanation of "state" still means stored information, in the sense that it is something "that is", rather than "that does". But this is one of those things whose precise definition is hard to enshrine, but we all sort of get what it means. — Flater, Aug 25 '21 at 06:58
I agree with the "smth that is" vs "smth that does" remark, but in everyday English state means something like "current way of being" or a "current condition of something"; it's only in technical fields (science, engineering, programming) where it explicitly involves information (e.g. a set of parameter values that describe the system at time t), and the term in programming/CS originated from this tradition. I do agree, in our field it does mean "stored information", but it also means the above - and this is important for notions like encapsulation, subtyping, and even practices like TDD. — Filip Milovanović, Aug 25 '21 at 12:51
E.g. you can differentiate between state as seen by clients (or black-box tests) vs that seen by derived classes. Similarly, the C++ mutable keyword helps you differentiate between client-facing state covered by `const` and internal state that isn't. LSP is formally defined, in part, in terms of a mapping telling you which states of the subtype correspond to which (potentially less numerous) states of the supertype - so there's this abstract notion of state (Liskov and Wing paper). It is true however that informally we very often use the term "state" to just mean "data". — Filip Milovanović, Aug 25 '21 at 12:51

score 1 · Answer 2 · answered Aug 24 '21 at 10:16

If "ability to handle money" is a property, then it's a boolean one, and it's used to know whether the machine is capable of handling money or not. If it's non-static and mutable then it can be used to prevent the machine from handling money by setting it to false.

Machine m = new Machine();
if (m.canHandleMoney()) {
   // this machine can handle money
   m.setCanHandleMoney(false);
   // now it can't
}

Could that be refering to behavior instead? The it's probably about injectable behavior:

Machine m = new Machine();
MoneyHandler h = new MoneyHandler();
m.setMonetHandler(h);

Otherwise behavior is not a property.

score 0 · Answer 3 · answered Aug 24 '21 at 09:46

I think he just uses the term property for two different things. Seems obvious to me, that he describes a behavior in your quote, not a technical "property", i.e a variable.

I don't have my copy handy right now, but I'm pretty sure it's just the colloquial use of the term "property". I.e. a property of a water slide is that it is slippery and you can slide down.

Definition of static property of object in OOP

3 Answers3

1

2

3