OOP design question
You can design your classes to be easily testable. Some would argue that classes that aren't easy to test are badly designed in general. It would be interesting to see a real example class that you are talking about.
that's not a side effect, that's the purpose of this function, if every modification of a member in a member function would be a side effect, the whole Object Oriented Design would be a side effect design, as the so called 'proper way' to access member variables is via accessor functions (setter/getter), so when you call
So the first CalcC has a side effect. That is, it modifies the program state by mutating c.
Init()
SetC(..)
Clear()
Reset()
CalcC()
you'd also have a 'side effect' by your definition.
from http://en.wikipedia.org/wiki/Side_effect_(computer_science)
In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world....[/quote]
Design A is perfectly fine.
that's not a side effect, that's the purpose of this function, if every modification of a member in a member function would be a side effect, the whole Object Oriented Design would be a side effect design, as the so called 'proper way' to access member variables is via accessor functions (setter/getter), so when you call
[quote name='Telastyn' timestamp='1342009482' post='4958000']
So the first CalcC has a side effect. That is, it modifies the program state by mutating c.
Init()
SetC(..)
Clear()
Reset()
CalcC()
you'd also have a 'side effect' by your definition.
from http://en.wikipedia....omputer_science)
In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world....[/quote]
Design A is perfectly fine.
[/quote]
The 2nd quote contradicts your first post, Design A most definitly has a side effect, and yes, OOP pretty much relies on side effects (This is why, in computer science we talk about methods rather than functions when we deal with OOP and also why C is considered a procedural language rather than a functional one)
that's not a side effect, that's the purpose of this function, if every modification of a member in a member function would be a side effect, the whole Object Oriented Design would be a side effect design, as the so called 'proper way' to access member variables is via accessor functions (setter/getter), so when you call
[quote name='Krypt0n' timestamp='1342082985' post='4958312']
[quote name='Telastyn' timestamp='1342009482' post='4958000']
So the first CalcC has a side effect. That is, it modifies the program state by mutating c.
Init()
SetC(..)
Clear()
Reset()
CalcC()
you'd also have a 'side effect' by your definition.
from http://en.wikipedia....omputer_science)
In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world....[/quote]
Design A is perfectly fine.
[/quote]
The 2nd quote contradicts your first post, [/quote]I don't see what could make you think that.
side effects are unexpected/unwanted effects. if you try to drive to work with your car, and you arrive, it's not a side effect. if you hit a bike while driving, that's a side effect. if the purpose of a member function is to calculate C for the object and this is the only think it does, it's not a side effect. Otherwise, what is the main effect, next to the side effect of this member function in Design A?
Design A most definitly has a side effect, and yes, OOP pretty much relies on side effects
(This is why, in computer science we talk about methods rather than functions when we deal with OOP and also why C is considered a procedural language rather than a functional one)
[/quote]that's why we software engineers and architects love you scientist ;)
side effects are unexpected/unwanted effects. if you try to drive to work with your car, and you arrive, it's not a side effect. if you hit a bike while driving, that's a side effect. if the purpose of a member function is to calculate C for the object and this is the only think it does, it's not a side effect. Otherwise, what is the main effect, next to the side effect of this member function in Design A?
In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world....[/quote] (2nd quote from your post)
side effects (in programming) have nothing to do with unexpected/unwanted behavior, (unexpected/unwanted behavior are called bugs, not side effects). Normally this is covered in software engineering degrees as part of the functional programming courses.
if you try to drive to work with your car, and you arrive, it's not a side effect.
No, but the fuel you burn is.
The position of your car changing is.
And yes, pretty much all of OO is side effects. Which means yes... member methods should be avoided. This is well known best practice (almost always phrased 'prefer free functions') for more than a decade now.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
