Definition of "Behaviour"?

Question

What is exactly meant when software-engineers talk about "behaviour" in contrast to "state" (Definition of "state")?

At a very basic, not-necessarily-OO level, "behavior" is any *visible* action or change of state, where "visible" means "seen by any component in the system", not just a human observer. — John Bode, Jan 08 '20 at 16:10
It reflects a basic distinction in all computation. Between values or variables which are the "state", and the operators which transform them according to rules (the "behaviour" in OO philosophy). In also appears in other guises, like the distinction between the "data access layer" (which more or less retrieves or saves state) and the "business logic layer" (which defines various transformations of that state). — Steve, May 29 '20 at 19:56

candied_orange · Answer 1 · 2020-05-29T15:02:36.407

14

Behaviour is decisions being made.

State is decisions being remembered.

When OOP people talk about behaviour what they mean is the gooey sticky part of the code base that has to be changed every time a business rule changes. Rather than state, what this is usually contrasted with is dry structural cerimonial code that exists mostly because the system or language requires it of us. A lot of work just goes into keeping these separate.

But if we're going to contrast behaviour with state then I'll flat out admit that the difference is just in our heads. Code and data are the same thing. This is something hackers love to exploit. We accept their data and they figure out how to make us treat it like code.

Behaviour is a construct of our minds about what we want the system to do. Behaviour code is code that focuses on that ideal. It's an illusion but it's what we're imagining when we say it. State is the result of what's already been done. It might be used in the decisions to come. We don't think of it as making the decisions. But again, this distinction is all in our heads. Really, code or data, behavior or state, it's all really just numbers.

But that doesn't mean it's a meaningless distinction. The computer might not care about the difference but the humans do. The differences comes from intent. We separate these ideas so we can make the behavior we expect clear.

edited May 29 '20 at 15:02

answered Jan 08 '20 at 08:42

candied_orange

102,279
24
197
315

3

That sounds poetic, philosophical and deep, but it is unhelpful and borderline nihilistic. Yes, if we look from far (or close) enough it's all electrons, so they are the same. Yes, it's mostly in our heads. That doesn't mean it's meaningless or an illusion. Taste is also in our heads, doesn't mean it is an illusion. You're muddying the waters, causing more confusion where there should be way less. – Robert Bräutigam Jan 08 '20 at 09:43
@RobertBräutigam rather than nihilism what I was asking you to do is go along with the self deception. I'm admitting it's all just numbers so we can move on to simply thinking of it as a useful distinction of intent. – candied_orange Jan 08 '20 at 09:46
The computer may not care about the disctinction, but the operating system does. Behaviour is generally permissioned read-execute, and state is generally permissioned read-write. – James_pic Jan 08 '20 at 17:52
1

@James_pic it's exactly because there is no inherent difference between them (they're all just numbers) that we have to have the OS manage what we insist that they should be. Computers would be a lot more secure if code was always code and data was always data. – candied_orange Jan 09 '20 at 00:43

Robert Bräutigam · Accepted Answer · 2020-01-08T08:12:34.883

There are multiple layers to the answer.

On the technical level, state is simply the instance variables of an object, and behavior are the methods. Both of these can be extended to other granularity units, like a group of objects or the whole system. Should be clear from the context.

On the semantic ("meaning") level, specifically for object-orientation, both have additional constraints. Not all methods constitute "real" behavior. Getter/setters methods are not behavior for example, because they don't really mean anything in the problem domain. Behavior needs to connect directly with the requirements in some form to be a real behavior.

There may be additional layers of meaning. For example in the context of Domain-Driven Design, I would expect methods to have an even more stricter connection with the vocabulary of the requirements (i.e. the Ubiquitous Language).

It's worth pointing out, that many projects settle for just the technical level, and even in the context of Domain-Driven Design many are completely ok with meaningless methods such as setters/getters in objects and still talk about "behavior" (or "responsibility") in some form. Which may confuse the issue somewhat.

score 1 · Answer 3 · answered Jan 08 '20 at 11:35

I think this is an interesting question, that not many people are aware of even asking.

From a general software perspective, I like to see it as follows:

Behaviour drives state, and state can potentially drive behaviour

It is a two-way relationship, because certain actions can trigger certain flows to be executed, while within some flows, certain actions can be triggered.

So, if we execute an action, like:

Click on a submit button to submit a form, different things might happen if the form is complete or incomplete, warnings might be triggered, emails might be sent, DB records might be created or updated, etc.

Each of these actions on the other hand, might trigger new actions to be taken, etc. So, it's clearly a two-way relationship.

From a more OO perspective, say, that an object, Dog, can perform an action, like, eatTreat().

When the dog eats, a TreatSupplier class might need to be updated internally, to reduce the biscuit amount by one.

If the biscuit count reaches 0, we can say that the biscuit supplier was put in a certain state due to an action taken by the dog.

These kind of relationship between state and behaviour is a big part of how OO-structured systems work.

score 0 · Answer 4 · answered Jan 05 '21 at 14:05

Dynamic Behavior of an item (a Software Component / a Software Unit) is the sequence of event occurences that is observable at the boundary of the item. (Sequence Diagrams, Timing Diagrams, Use-case Diagrams, Message Sequence Charts...)

Static Behavior of an item (a Software Component / a Software Unit) are the relationships of how the data is organized physically. (File Include Structure, Class Diagrams, Component Decomposition...)

Definition of "Behaviour"?

4 Answers4

Linked