OOP Question

[RSH]

I was reading a tutorial on OOP principals and design and I stumbled on
something that I don't understand. The tutorial used a Oven class. In that
class there was a private field called temperature.

class Oven {
private int _temperature;

public int Temperature {
get {
return _temperature;
}
set {
_temperature = value;
}
}
}

This is the implementation I would normally employ. BUT... The article
says...
"The type Oven exposes its temperature as a property, which is a direct
reference to the variable _temperature. This means that the internal oven
temperature implementation is tied directly to its external interface. The
point of good object-oriented programming is to avoid this sort of
programming."

That seems strange to me...what if I have to expose temperature? What if my
cookie object needs to preheat the oven to 350 degrees dont I need to
monitor the temperature of the oven object?

Damn just when I started to think I was getting OOP!

Thanks,

Ron

[Jon Skeet [C# MVP]]

On Dec 7, 1:32 pm, "RSH" <way_beyond_o.. [e-mail] e:

I was reading a tutorial on OOP principals and design and I stumbled on
something that I don't understand. The tutorial used a Oven class. In that
class there was a private field called temperature.

<snip>

This is the implementation I would normally employ. BUT... The article
says...
"The type Oven exposes its temperature as a property, which is a direct
reference to the variable _temperature. This means that the internal oven
temperature implementation is tied directly to its external interface. The
point of good object-oriented programming is to avoid this sort of
programming."

That sounds like a bad book to me. The implementation will always be
tied to the interface - the point is to avoid the *reverse* being
true, i.e. exposing the implementation itself as the interface.

I've certainly heard people saying that properties should almost
always be avoided etc, but it's not a particularly commonly-held view.

Jon

[Nicholas Paldino [.NET/C# MVP]]

Ron,

I am curious, what does the article recommend is the workaround? I
think that what it is trying to say is that you would have a Temperature
object which you would expose which would expose all the details of working
with temperature.

Of course, eventually, one will reach the point of diminishing returns,
meaning that you could only extend this so far before it becomes impossible
to work with (expose an object for temperature, which exposes an object for
degrees, etc, etc).

Oh, and the cookie wouldn't change the temperature, the Baker instance
would. The Baker instance would add the Cookie to the Sheet, and then add
the Sheet to the Oven. Then the Bake method would be called on the Oven,
which would change the Baked property of the individual Cookie instances on
the sheet over time.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"RSH" <wa************ *@yahoo.comwrot e in message
news:e9******** ******@TK2MSFTN GP02.phx.gbl...

>I was reading a tutorial on OOP principals and design and I stumbled on
something that I don't understand. The tutorial used a Oven class. In
that class there was a private field called temperature.

class Oven {
private int _temperature;

public int Temperature {
get {
return _temperature;
}
set {
_temperature = value;
}
}
}

This is the implementation I would normally employ. BUT... The article
says...
"The type Oven exposes its temperature as a property, which is a direct
reference to the variable _temperature. This means that the internal oven
temperature implementation is tied directly to its external interface. The
point of good object-oriented programming is to avoid this sort of
programming."

That seems strange to me...what if I have to expose temperature? What if
my cookie object needs to preheat the oven to 350 degrees dont I need to
monitor the temperature of the oven object?

Damn just when I started to think I was getting OOP!

Thanks,

Ron

[RSH]

Nicholas and Jon,

I appreciate both of your input...I highly respect the both of you and have
learned alot from you both.

This is the solution that they suggest:

delegate void OnTemperature( int temperature);

class Oven {
private int _temperature;
OnTemperature _listeners;

public void BroadcastTemper ature() {
_listeners( _temperature);
}
public void AddTemperatureL istener( OnTemperature listener) {
_listeners += listener;
}
}
class Controller {
public Controller( Oven oven) {
oven.AddTempera tureListener(
new OnTemperature( this.OnTemperat ure));
}
public void OnTemperature( int temperature) {
Console.WriteLi ne( "Temperatur e (" + temperature + ")");
}
}http://en.csharp-online.net/CSharp_Coding_S olutions%E2%80% 94Dont_Expose_a _Class_Internal _StateRon"Nicho las
Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote in message
news:10******** *************** ***********@mic rosoft.com...

Ron,

I am curious, what does the article recommend is the workaround? I
think that what it is trying to say is that you would have a Temperature
object which you would expose which would expose all the details of
working with temperature.

Of course, eventually, one will reach the point of diminishing returns,
meaning that you could only extend this so far before it becomes
impossible to work with (expose an object for temperature, which exposes
an object for degrees, etc, etc).

Oh, and the cookie wouldn't change the temperature, the Baker instance
would. The Baker instance would add the Cookie to the Sheet, and then add
the Sheet to the Oven. Then the Bake method would be called on the Oven,
which would change the Baked property of the individual Cookie instances
on the sheet over time.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"RSH" <wa************ *@yahoo.comwrot e in message
news:e9******** ******@TK2MSFTN GP02.phx.gbl...

>>I was reading a tutorial on OOP principals and design and I stumbled on
something that I don't understand. The tutorial used a Oven class. In
that class there was a private field called temperature.

class Oven {
private int _temperature;

public int Temperature {
get {
return _temperature;
}
set {
_temperature = value;
}
}
}

This is the implementation I would normally employ. BUT... The article
says...
"The type Oven exposes its temperature as a property, which is a direct
reference to the variable _temperature. This means that the internal oven
temperature implementation is tied directly to its external interface.
The point of good object-oriented programming is to avoid this sort of
programming. "

That seems strange to me...what if I have to expose temperature? What if
my cookie object needs to preheat the oven to 350 degrees dont I need to
monitor the temperature of the oven object?

Damn just when I started to think I was getting OOP!

Thanks,

Ron

[Jon Skeet [C# MVP]]

On Dec 7, 2:12 pm, "RSH" <way_beyond_o.. [e-mail] e:

I appreciate both of your input...I highly respect the both of you and have
learned alot from you both.

This is the solution that they suggest:

<snip>

So basically an event model with no direct "read on demand" other than
telling *all* listeners the temperature, and also with no control over
the temperature.

That kind of thing will be appropriate *sometimes*, but far from
always - in particular, I can't see why one client should be able to
make the oven notify all the other listeners of the temperature,
whether or not it's changed (the most obvious reason for wanting to
know).

Jon

[RSH]

Jon,

Thank you...I thought I was losing it! I agree the Observer pattern is
without question a powerful pattern and has its place...but this seemed to
me like someone was overcomplicatin g design just to match an acedemic
interpretation, and not looking at the maintainability of actual coding. i
mean it seems to me that if you have a complex series of objects
communicating like this it would be almost impossible to debug and unit
test.

Ron
"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:cb******** *************** ***********@w40 g2000hsb.google groups.com...

On Dec 7, 2:12 pm, "RSH" <way_beyond_o.. [e-mail] e:

>I appreciate both of your input...I highly respect the both of you and
have
learned alot from you both.

This is the solution that they suggest:

<snip>

So basically an event model with no direct "read on demand" other than
telling *all* listeners the temperature, and also with no control over
the temperature.

That kind of thing will be appropriate *sometimes*, but far from
always - in particular, I can't see why one client should be able to
make the oven notify all the other listeners of the temperature,
whether or not it's changed (the most obvious reason for wanting to
know).

Jon

[Mythran]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote in
message news:10******** *************** ***********@mic rosoft.com...

Ron,

I am curious, what does the article recommend is the workaround? I
think that what it is trying to say is that you would have a Temperature
object which you would expose which would expose all the details of
working with temperature.

Of course, eventually, one will reach the point of diminishing returns,
meaning that you could only extend this so far before it becomes
impossible to work with (expose an object for temperature, which exposes
an object for degrees, etc, etc).

Oh, and the cookie wouldn't change the temperature, the Baker instance
would. The Baker instance would add the Cookie to the Sheet, and then add
the Sheet to the Oven. Then the Bake method would be called on the Oven,
which would change the Baked property of the individual Cookie instances
on the sheet over time.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"RSH" <wa************ *@yahoo.comwrot e in message
news:e9******** ******@TK2MSFTN GP02.phx.gbl...

>>I was reading a tutorial on OOP principals and design and I stumbled on
something that I don't understand. The tutorial used a Oven class. In
that class there was a private field called temperature.

class Oven {
private int _temperature;

public int Temperature {
get {
return _temperature;
}
set {
_temperature = value;
}
}
}

This is the implementation I would normally employ. BUT... The article
says...
"The type Oven exposes its temperature as a property, which is a direct
reference to the variable _temperature. This means that the internal oven
temperature implementation is tied directly to its external interface.
The point of good object-oriented programming is to avoid this sort of
programming. "

That seems strange to me...what if I have to expose temperature? What if
my cookie object needs to preheat the oven to 350 degrees dont I need to
monitor the temperature of the oven object?

Damn just when I started to think I was getting OOP!

Thanks,

Ron

In my case, where I AM THE BAKER, the BAKED property is an enumeration.

Values of BAKED:

Uncooked,
Undercooked,
Burned,
DUDEYourHouseIs OnFire
Temperature property is similar:

Off,
LukeWarm,
TemperatureOfTh eSun,
HotterThanTheSu n,
DUDEYourHouseIs OnFire

:)

Mythran

[Jeff Louie]

Hmmm... Get and set the _desired_ temperature seems to be an attribute
of the oven. When I want to know the actual temperature of our oven I
need to use a thermometer. I suppose some ovens have a built in
thermometer, in which case the oven class could contain a thermometer
with a get only property. I suppose the oven could beep when the preset
temperature is reached, so there could be an event that fires when the
desired temperature is reached.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Registered User]

On Fri, 07 Dec 2007 15:27:54 -0800, Jeff Louie <an*******@devd ex.com>
wrote:

>Hmmm... Get and set the _desired_ temperature seems to be an attribute
of the oven. When I want to know the actual temperature of our oven I
need to use a thermometer. I suppose some ovens have a built in
thermometer, in which case the oven class could contain a thermometer
with a get only property. I suppose the oven could beep when the preset
temperature is reached, so there could be an event that fires when the
desired temperature is reached.

That is similar to my oven. I can set the temperature through one
control and read the temperature using a different control. Both
controls are public members of some oven-control type. All objects of
type oven should have a controller member. This indirection is likely
what the original quote in question meant.

"The type Oven exposes its temperature as a property, which is a
direct reference to the variable _temperature. This means that the
internal oven temperature implementation is tied directly to its
external interface. The point of good object-oriented programming is
to avoid this sort of programming."

regards
A.G.

[Jeff Louie]

AG... Without access to the tutorial I really don't know what the author
meant:)

Off the top of my head, I don't see any problem with the Oven class
having a get temperature property. The use of a get Temperature as a
_property_ still involves indirection. For instance, say get is in
degrees F. In the future, the oven could be redesigned using an internal
hidden "thermomete r" which "reports and stores" in degrees C without
affecting the public view which could still return in degrees F.

As I see it, the use of events instead of get only is a different design
decision: get/polling vs push/events. An "event",
OnTemperatureCh angedOneDegreeF :) would be useful to avoid polling.

FWIW, some have argued against the use of the term "Broadcaste rs" or
"Broadcast" with events and listeners. I certainly used that naming
convention in the past, but Broadcast in IP is used to notify all nodes
and the term Broadcaster fell out of favor for events with a limited
domain of listeners.

Regards,
Jeff

>That is similar to my oven. I can set the temperature through one

control and read the temperature using a different control. Both
controls are public members of some oven-control type. All objects of
type oven should have a controller member. This indirection is likely
what the original quote in question meant.
<

*** Sent via Developersdex http://www.developersdex.com ***