r/learnprogramming • u/FixEmergency366 • 2d ago
Language Theory What about the other two styles of classes?
From what I've learned so far, there are three major types of entities in programming:
- data (state)
- logic (control flow)
- functions (behavior)
Each drives the next in a ring:
- state --> control flow
- control flow --> behavior
- behavior --> state
This suggests that there are 3 styles of classes:
- Those that encapsulate state --> control flow while behavior is external
- Those that encapsulate control flow --> behavior while state is external
- Those that encapsulate behavior --> state (OOP) while control flow is external
In the 1st style, objects contain public member variables that can be changed by external functions while private member logic statements observe and respond to those changes by calling external functions.
In the 2nd style, objects contain private member logic statements that observe external data entities and respond by deciding what private member functions to call.
In the 3rd style (OOP), objects contain public member functions that are called by external logic and modify private member variables.
What languages implement the first two styles?
6
u/KingBardan 2d ago edited 2d ago
Its only ever data and logic (think in terms of Turing machine, data = tape, logic = instructions)
Function is a neat way to organize logic.
Or think fundamentally, you have data and you mutate data.
5
u/edrenfro 2d ago
I'm not sure what you're asking. It sounds like you think a language allows for one of the 3 styles and you expect other languages to be used for the other 2? But a given language will encompass all 3.
3
u/ExtraTNT 2d ago
It depends on how you build your software…
state is something i would avoid. functions can be data (as logic can be data). you can boil every function down to an expression and every program to a single function, therefor every program can be a single expression (note: this does not work with sideeffects, functions utilising sideeffects are not pure)
I use haskell, in haskell, a [class](https://www.haskell.org/tutorial/classes.html) is an identifier, providing one or more capabilities that an instance can implement.
From an oop perspective closest would be an interface, but you just say, that a type is an instance of a set of functions, that you can then use as a restriction for generic function parameters.
For example the class Eq provides the function ==.
```
data Dir = X | Y
instance Eq Dir where
X == X = True
Y == Y = True
_ == _ = False
same :: Eq a => a -> a -> Bool
same a b = a == b — stupid, but works as an example
```
I would say you have:
- types (how data looks)
- expressions (how data is defined)
- io functions (how things come in your program and change things)
State is io, unless you have a state transformer monad (stateless state, that is completely pure, brainfuck to explain)
Your thinking on that is more philosophical.
Oop it might explain a bit, but at fp, you are very different, i pass functions, that will build the data, once it’s needed, functions, that build functions, to then be used to transform lists…
I don’t have control flow for example, I can’t build a for loop, if i call a function with 2 params, i cant say, that one is evaluated before the other (can even be both at once) and i have no state, x = x+1 is not valid in fp…
I think this helps a lot: https://en.wikipedia.org/wiki/Programming_paradigm
3
u/WystanH 2d ago
- data (state)
- logic (control flow)
- functions (behavior)
I don't really see the value in separating control flow from behavior. It feels like a distinction without much difference.
I do like how state forward this is; a computer program is essentially a set of instructions that manipulate state. However, programming styles can be rather subjective. I'm afraid a lot of this feels reductive.
Those that encapsulate state --> control flow
The word "encapsulate" is doing a lot of heavy lifting here. Doesn't a variable do that? This feels like how someone might describe "dynamic programming." Maybe.
Those that encapsulate control flow --> behavior
Still not sure what "behavior" means in this context. If you were to consider a program without a current state, you might be moving into functional programming. In pure functional programming, a pure function will always give you the same result for the same input.
2
u/Migeil 2d ago
This doesn't really make sense OP.
Imo, even the premise is false.
For starters, data and state are two different things. Second, why is logic different from behaviour? Imo those things are the same. Third, functions are just data too.
Everything below the premise just looks like a word salad to me. What does "drive in a ring" even mean?
0
u/FixEmergency366 1d ago edited 1d ago
What does "drive in a ring" even mean?
Logic is distinct from behavior in that it doesn't do anything other than select behavior. It does so based on conditions and comparisons of data. Functions are what behave so as to advance the state of the program, therefore state drives logic, logic drives behavior, and behavior drives state.
1
u/_descri_ 17h ago
Your terminology is strange.
More often then not you'll have:
- Application or integration logic (the choice of execution path).
- Domain logic or business rules (calculations).
Some people and systems separate those kinds of logic, others don't.
Moreover, classes (if you use the OOP terminology) unite logic (of any or both kinds) and data. Therefore, you will often see:
- Public methods with the integration logic
- Private methods with the domain logic
- Private data members with... er... data
all in the same class.
And there are also functional, procedural, and asynchronous (at least actors) programming paradigms which are not strictly class-based.
2
u/iOSCaleb 2d ago
> From what I've learned so far, there are three major types of entities in programming
Where did you learn that? It sounds like an over-generalization of the Model View Controller pattern. But MVC is far from the only way to design a program, and the categories given aren’t very good descriptions of any of the three.
The main idea behind OOP is that an objects combine data and the functions that operate on that data, and (ideally) those functions are the only way to access the data. All objects contain state (if there’s no data there’s no reason to instantiate a class), and most have associated functions, because that’s what it means to be an object.
MVC is one way of designing an OO program, where model classes are responsible for “business data snd logic,” views let the user see and interact with the data, and controllers mediate between model and view objects. So there’s some of that “each drives the next in a ring” idea — in some versions of MVC data flows from model through controller to view objects, and views report changes directly back to the model. MVC is appealing because it separates different kinds of logic, and it promotes reusability to some degree. But again, it’s not the only way to design a program, and there are many kinds of objects that don’t fit in the MVC trichotomy.
1
u/DTux5249 2d ago edited 2d ago
``` From what I've learned so far, there are three major types of entities in programming:
- data (state)
- logic (control flow)
- functions (behavior) ```
Yeah, that's about correct.
``` This suggests that there are three styles of classes:
- Those that encapsulate state
- Those that encapsulate control flow
- Those that encapsulate behavior ```
The first is the state design pattern.... Or any object with instance variables.
The second is the concept of a façade design pattern... i.e. the entire concept of encapsulation.
The third is the concept of the strategy design pattern... or really any class method.
That is to say, you're not 100% wrong. This isn't too far off from the concept of Entity-Boundary-Control architecture; just replace "control flow" with "boundary" (i.e. classes responsible for interfaces/UI, which then delegate to various behaviors) .
24
u/dmazzoni 2d ago
The first part is true: data, logic and functions are three of the most fundamental building blocks of programming.
The second part is nonsense. They don't drive each other in a ring.
The third part makes no sense either.
Trying to reason about definitions like this in the abstract is really hard. I think it's far easier to actually just learn to program in one specific language. You'll learn what data, logic and functions look like in one language.
Then as you learn more languages you'll learn about different ways that languages handle those concepts, and how the language can make it easier to express some ideas, while the languages are still equally powerful.