Best Practices -- Naming Convention Question

[42]

Hi,

Stupid question:

I keep bumping into the desire to create classes and properties with the
same name and the current favored naming conventions aren't
automatically differentiating them... (both are "Pascal Case" with no
leading or trailing qualifiers).

For example... I'll be modelling something, e.g. a computer, and I'll
create some classes:

Monitor, Cpu, Keyboard, Mouse...

And then I'll define a Computer Class...

class Computer
Monitor _monitor;
Cpu _cpu;
Keyboard _keyboard;

and then I get to setting some simple accessors and I'm stuck with the
inclination to do this:

Monitor Monitor {get ... set...}
Cpu Cpu {get ... set...}
Keyboard Keyboard {get ... set ...}

Now this does compile, but I think it makes the code more unreadable,
and sooner or later I'll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i'll be facing
especially cryptic build error messages as a result. Or perhaps worse:
cryptic behaviour if it happens to build successfully.

And I don't really want my accessors called 'TheMonitor' and as the
practice of naming the classes "CMonitor or clsMonitor" etc have gone
out of favour...

So what are others doing?

regards,
Dave

[Peter Kirk]

"42" <no****@nospam.com> skrev i en meddelelse
news:MP************************@shawnews.vf.shawca ble.net...

I keep bumping into the desire to create classes and properties with the
same name and the current favored naming conventions aren't
automatically differentiating them... (both are "Pascal Case" with no
leading or trailing qualifiers).

For example... I'll be modelling something, e.g. a computer, and I'll
create some classes:

Monitor, Cpu, Keyboard, Mouse...

And then I'll define a Computer Class...

class Computer
Monitor _monitor;
Cpu _cpu;
Keyboard _keyboard;

and then I get to setting some simple accessors and I'm stuck with the
inclination to do this:

Monitor Monitor {get ... set...}
Cpu Cpu {get ... set...}
Keyboard Keyboard {get ... set ...}

Now this does compile, but I think it makes the code more unreadable,
and sooner or later I'll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i'll be facing
especially cryptic build error messages as a result. Or perhaps worse:
cryptic behaviour if it happens to build successfully.

And I don't really want my accessors called 'TheMonitor' and as the
practice of naming the classes "CMonitor or clsMonitor" etc have gone
out of favour...

So what are others doing?

I go the "Monitor Monitor { get; set; }" way. I, like you, think it looks a
little ugly. I also think underscores on instance variables look ugly, but
there you go.

I am still tempted to "revert" to the way I did it in java, and write
getters and setters (starting with lower-case letters):
Monitor getMonitor() {
return monitor;
}
void setMonitor(Monitor monitor){
this.monitor = monitor;
}
for example. (Personally I do like this - I can see the methods for "get"
and "set", and to me it is obvious what they do. If I just see a property
called Monitor it is not immediately clear if you can get and set, or only
get for example).

Peter

[Oliver Sturm]

42 wrote:

So what are others doing?

I do it the way you're describing, only I don't use an underscore for
fields.

private Monitor monitor;
public Monitor Monitor { get { ... } }

I understand your argument about ambiguity, but the counter-argument is
that by this naming convention it becomes immediately clear to someone
reading your code that the Monitor property of your class is most
probably of the type with the same name.

I think that at least the convention about naming fields the way I do is
part of MS guidelines, although I forgot where I once found that.
Oliver Sturm
--
omnibus ex nihilo ducendis sufficit unum
Spaces inserted to prevent google email destruction:
MSN oliver @ sturmnet.org Jabber sturm @ amessage.de
ICQ 27142619 http://www.sturmnet.org/blog

[Jon Skeet [C# MVP]]

42 <no****@nospam.com> wrote:

<snip>

Now this does compile, but I think it makes the code more unreadable,
and sooner or later I'll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i'll be facing
especially cryptic build error messages as a result.

I agree it looks a bit odd to start with, but it does work - I very
rarely have any problems with ambiguities. It's definitely the way MS
go in various APIs, and it's very readable for client code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Nick Malik [Microsoft]]

Hi Dave,

I guess I'll go counter to what everyone else is saying.

I keep bumping into the desire to create classes and properties with the
same name and the current favored naming conventions aren't
automatically differentiating them... (both are "Pascal Case" with no
leading or trailing qualifiers).

For example... I'll be modelling something, e.g. a computer, and I'll
create some classes:

Monitor, Cpu, Keyboard, Mouse...

And then I'll define a Computer Class...

class Computer
Monitor _monitor;
Cpu _cpu;
Keyboard _keyboard;

and then I get to setting some simple accessors and I'm stuck with the
inclination to do this:

Monitor Monitor {get ... set...}
Cpu Cpu {get ... set...}
Keyboard Keyboard {get ... set ...}

Now this does compile, but I think it makes the code more unreadable,
and sooner or later I'll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i'll be facing
especially cryptic build error messages as a result. Or perhaps worse:
cryptic behaviour if it happens to build successfully.

I, like you, find the syntax
private Monitor _monitor = new Monitor()
Monitor Monitor { get{} set{} )
to be confusing and potentially problematic.

A "Monitor" as both a class and a property of another class is not, in my
opinion, a good clean way of understanding and describing the problem.

First off, if you model your system based on behavior, and not nouns, then
this kind of thing is rare because you do not often compose an object of
other objects that you then expose to outside manipulation (as you are doing
here).

Secondly, I would say that you lose an opportunity to express context when
you create your property names like this. If you have a Monitor object that
is of type "Equipment" and your system is composed of multiple bits of
Equipment, then you are unlikely to expose a "Monitor" property. You are
more likely to expose a property that would return a list of monitors from
the list if items in the system (since a system can validly have zero, one,
two, or more monitors associated with it).

On the other hand, from a naming convention, I would say that the property
name should be composed of an Adjective followed by the Object name in such
a way as to express context. Therefore:

class Computer {
public PrimaryMonitor Monitor { get ... set ... }
public SecondaryMonitor Monitor { get... set ... }
public List<Monitor> GetMonitors()
{ ... }
}
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[42]

In article <MP************************@msnews.microsoft.com >,
sk***@pobox.com says...

42 <no****@nospam.com> wrote:

<snip>

Now this does compile, but I think it makes the code more unreadable,
and sooner or later I'll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i'll be facing
especially cryptic build error messages as a result.

I agree it looks a bit odd to start with, but it does work - I very
rarely have any problems with ambiguities. It's definitely the way MS
go in various APIs, and it's very readable for client code.

Thanks for all the responses. I guess I won't worry about it then, as
everyone seems comfortable with it...

I wanted to avoid writing code that would get me shot at a code review,
but it looks like the practice is generally accepted, after all.

:)

thanks,
dave

[42]

In article <TO********************@comcast.com>,
ni*******@hotmail.nospam.com says...

Hi Dave,

I guess I'll go counter to what everyone else is saying.

I keep bumping into the desire to create classes and properties with the
same name and the current favored naming conventions aren't
automatically differentiating them... (both are "Pascal Case" with no
leading or trailing qualifiers).

For example... I'll be modelling something, e.g. a computer, and I'll
create some classes:

Monitor, Cpu, Keyboard, Mouse...

And then I'll define a Computer Class...

class Computer
Monitor _monitor;
Cpu _cpu;
Keyboard _keyboard;

and then I get to setting some simple accessors and I'm stuck with the
inclination to do this:

Monitor Monitor {get ... set...}
Cpu Cpu {get ... set...}
Keyboard Keyboard {get ... set ...}

Now this does compile, but I think it makes the code more unreadable,
and sooner or later I'll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i'll be facing
especially cryptic build error messages as a result. Or perhaps worse:
cryptic behaviour if it happens to build successfully.

I, like you, find the syntax
private Monitor _monitor = new Monitor()
Monitor Monitor { get{} set{} )
to be confusing and potentially problematic.

A "Monitor" as both a class and a property of another class is not, in my
opinion, a good clean way of understanding and describing the problem.

First off, if you model your system based on behavior, and not nouns, then
this kind of thing is rare because you do not often compose an object of
other objects that you then expose to outside manipulation (as you are doing
here).

Hmm. Not sure I follow you. methods/events model behaviour, and have
'verb' names... like Initialize, Paint, LoadObject, etc.. but
properties, at least in my experience are frequently nouns.

And I frequently create composite objects and expose the properties.
Secondly, I would say that you lose an opportunity to express context when
you create your property names like this. If you have a Monitor object that
is of type "Equipment" and your system is composed of multiple bits of
Equipment, then you are unlikely to expose a "Monitor" property. You are
more likely to expose a property that would return a list of monitors from
the list if items in the system (since a system can validly have zero, one,
two, or more monitors associated with it). On the other hand, from a naming convention, I would say that the property
name should be composed of an Adjective followed by the Object name in such
a way as to express context. Therefore:

class Computer {
public PrimaryMonitor Monitor { get ... set ... }
public SecondaryMonitor Monitor { get... set ... }
public List<Monitor> GetMonitors()
{ ... }
}

Fair enough, in the case of Monitors at least. It was just an example
but even working within it....

What about Motherboards or Cases. PCs only ever have one of each. Its
not a 'PrimaryMotherboard", there isn't going to be a list of them. I'm
not sure what 'context' you would add that wouldn't feel contrived.

I think in general, I don't bump into it when using "generic" classes,
like Point, or Stack, HashTable, or Button...or my own classes with that
sort of broad utility... I mean my form class will have a
Button GoButton,
Button NextButton,
Button ExitButton, etc...

It happens when I have to create a specific class for a very specific
peice of an application.

e.g. If I want a custom "ExitButton", I inherit a new class from
"Button" called "ExitButton"... and then I end up with

ExitButton ExitButton(...)

:/

[Tom Z.]

I use the same, but I am not really comfortable with it. This does follow MS
naming convention - name a property with the type name if possible, e.g.,
Color property of type Color.

I also use the leading underscore for private fields. I can't stand the
aspect of the MS naming convention where private field names clash with
constructor and method parameter names. This forces you to use "this."
everywhere which is nasty.

I am not totally convinced the MS naming conventions are as well thought out
as folks think, and I am not convinced they will stand the test of time.

We had a better naming convention in C++ that had fewer problems, but when
we switched to C#, we adopted the MS naming convention. I'm not sure that was
the best idea...

"42" wrote:

Hi,

Stupid question:

I keep bumping into the desire to create classes and properties with the
same name and the current favored naming conventions aren't
automatically differentiating them... (both are "Pascal Case" with no
leading or trailing qualifiers).

For example... I'll be modelling something, e.g. a computer, and I'll
create some classes:

Monitor, Cpu, Keyboard, Mouse...

And then I'll define a Computer Class...

class Computer
Monitor _monitor;
Cpu _cpu;
Keyboard _keyboard;

and then I get to setting some simple accessors and I'm stuck with the
inclination to do this:

Monitor Monitor {get ... set...}
Cpu Cpu {get ... set...}
Keyboard Keyboard {get ... set ...}

Now this does compile, but I think it makes the code more unreadable,
and sooner or later I'll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i'll be facing
especially cryptic build error messages as a result. Or perhaps worse:
cryptic behaviour if it happens to build successfully.

And I don't really want my accessors called 'TheMonitor' and as the
practice of naming the classes "CMonitor or clsMonitor" etc have gone
out of favour...

So what are others doing?

regards,
Dave

[Jon Skeet [C# MVP]]

<=?Utf-8?B?VG9tIFou?= <none>> wrote:

I use the same, but I am not really comfortable with it. This does follow MS
naming convention - name a property with the type name if possible, e.g.,
Color property of type Color.

I also use the leading underscore for private fields. I can't stand the
aspect of the MS naming convention where private field names clash with
constructor and method parameter names. This forces you to use "this."
everywhere which is nasty.

There *is* no such aspect to the MS convention - it doesn't tell you
how you should name private variables.

However, you don't need to use "this" everywhere - only in places where
you need to refer to the variable directly and have a local variable
with the same name. That tends to happen in constructors, but not
elsewhere, which I don't think is too bad, personally.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Oliver Sturm]

Tom Z. wrote:

I also use the leading underscore for private fields. I can't stand the
aspect of the MS naming convention where private field names clash with
constructor and method parameter names. This forces you to use "this."
everywhere which is nasty.

You have to use it only in a few places, really. I usually never get
parameters passed into methods that have the same names as instance
fields - and if that should happen, the local method variable will be
used if I don't write "this.", which is almost certainly what I want in
those cases.

In constructors, you are right of course. But I really like that
concept, because I find it nice to read

this.param1 = param1;
...

Makes things clear for me immediately. And this is just about the only
situation where I regularly use "this".

Oliver Sturm
--
omnibus ex nihilo ducendis sufficit unum
Spaces inserted to prevent google email destruction:
MSN oliver @ sturmnet.org Jabber sturm @ amessage.de
ICQ 27142619 http://www.sturmnet.org/blog

[Nick Malik [Microsoft]]

"Tom Z." <none> wrote in message
news:7C**********************************@microsof t.com...

I use the same, but I am not really comfortable with it. This does follow
MS
naming convention - name a property with the type name if possible, e.g.,
Color property of type Color.

Nonsense. Of all the many hundreds of classes within the framework, there
are maybe 30 that use this naming convention, primarily because this was the
convention used in other APIs. If you look at the parts of the framework
that do not directly refer to Win32 API calls, you will NOT see this pattern
followed. The name of the property is different from the name of the
property type in nearly every case.
I also use the leading underscore for private fields. I can't stand the
aspect of the MS naming convention where private field names clash with
constructor and method parameter names. This forces you to use "this."
everywhere which is nasty.

I tend to use underscode as well. The API naming guidelines do not cover
what you call your private fields.

However, I haven't seen the need for 'this' that often.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[Nick Malik [Microsoft]]

Hi Dave

First off, if you model your system based on behavior, and not nouns,
then
this kind of thing is rare because you do not often compose an object of
other objects that you then expose to outside manipulation (as you are
doing
here).
Hmm. Not sure I follow you. methods/events model behaviour, and have
'verb' names... like Initialize, Paint, LoadObject, etc.. but
properties, at least in my experience are frequently nouns.

This is true. It is common to use nouns for properties (plural if they
represent a collection) and verbs for methods. I was not arguing with that.

And I frequently create composite objects and expose the properties.
That is what I was arguing with. Take a moment and dig through the
Framework. Look specifically for an area that you use frequently where
there is unlikely to be a lot of reliance on Win32 to drive the naming (iow,
avoid System.Drawing and stuff like that). Open up 20 classes and look at
their methods. Count the total number of methods and compare with the
number of methods that return an object instead of a base type like String
or Int. Now, look at the names of the types compared to the names of the
properties. You will see that, in practice, it is less common than you may
think to return a type (data objects do this more than others, but my
observation still holds... it is less than you may think). You will also
notice that it is downright rare for the name of the property to be the same
as a public type.

Design works best when classes model behavior and the data goes along for
the ride. If you decide what a class is for, and you can answer the
question: "What does this class encapsulate?" then you are moving away from
rote advice into the realm of real design.

In a system of interaction objects, where each has a behavior, it is very
uncommon for an object to expose a property that is simply another object.
That would occur if the "parent" object is a mediator or proxy, but the rest
of the time, it is rare at best. That is because behavior isn't normally
heirarchical. It also means that if object A is composed of objects B and
C, and objects B and C are directly exposed, that object A effectively does
"B activities" and "C activities" as well as "A activities" which doesn't
really make logical sense.

It is perfectly appropriate to create and object and assign it into another
object. I have nothing against composition. However, you also want to
maintain encapsulation. Therefore, for a property with an object type, you
should mark a "yellow flag" next to any property that has both a getter and
a setter. Either the object consumes another object (and uses it
internally), or an object creates another object (factory methods). Having
both should be rare. If you cannot do it with your current design, then I
would suggest that this should be an indicator that your current design may
have other, more structural, flaws.

Secondly, I would say that you lose an opportunity to express context
when
you create your property names like this. If you have a Monitor object
that
is of type "Equipment" and your system is composed of multiple bits of
Equipment, then you are unlikely to expose a "Monitor" property. You are
more likely to expose a property that would return a list of monitors
from
the list if items in the system (since a system can validly have zero,
one,
two, or more monitors associated with it).

On the other hand, from a naming convention, I would say that the
property
name should be composed of an Adjective followed by the Object name in
such
a way as to express context. Therefore:

class Computer {
public PrimaryMonitor Monitor { get ... set ... }
public SecondaryMonitor Monitor { get... set ... }
public List<Monitor> GetMonitors()
{ ... }
}

Fair enough, in the case of Monitors at least. It was just an example
but even working within it....

What about Motherboards or Cases. PCs only ever have one of each. Its
not a 'PrimaryMotherboard", there isn't going to be a list of them. I'm
not sure what 'context' you would add that wouldn't feel contrived.

And I'm still not sure why you would have individual properties for things
like this. Objects are not just data containers. I cannot think of a
problem, even surrounding this arbitrary data example, that I would model in
that way.

Let me imagine for a moment that I'm creating the system configurator page
on the Dell site. On that page, you are provided with system composition
options based on the model of computer you want. Pick an Optiplex and get
options: which motherboard, which one or two monitors, etc.

So, I have these components. I have constraints on them to decide what to
display and what to allow the customer to select from. So, let's look at
the problem. The user wants to see only the options available. So we need
to display sections on the web page that allow them to select their options.
We also need to collect enough information to display a bill-of-materials
for our new computer, so that the Dell manufacturing system can build and
ship it.

Two needs: model and view. However, are we talking about computers? No.
We are talking about choices. The user has choices. Each choice has
constraints about how to display it (we have to give the user help in
picking a choice, don't we?). The result of making a choice: we return a
"part". Aha! We've found a place where we can return an object!... but why
would we? It's an object that handles how to display information about a
part. It doesn't represent the part itself. So when querying the list of
selected parts from the object, when it comes time to display or even
persist the selections, why would we return a "displayable part" when we can
hand back a simple part number? That's a string.

Class Part
{
string _PartNumber;
string _Description;
public Part(InitPartNumber, InitDescription)
{
_PartNumber = InitPartNumber;
_Description = InitDescription;
}
public PartNumber { get { return _PartNumber;}}
public Description { get { return _Description; }}
}
Class ConfigChoice
{
private string Style;
private string Title;
private string HelpText;
private string Description;
private string<List> _PartList;
public void DisplaySelect()
{
// emit the HTML for the drop-down list where the user selects the
part number when they find the part description they want.
}
}
Class BaseSystemConfigurator
{
private List<ConfigChoice> _ConfigChoices;
public BaseSystemConfigurator(string ModelVersion)
{
// look up initial default configuration from a database
// and store the displayable form of the configuration in a
collection
_ConfigChoices = TranslationLayer.GetConfig(ModelVersion);
}
public void DrawChoices()
{
foreach (ConfigChoice ch in _ConfigChoices)
{
ch.DisplaySelect();
}
}
}

So, if you look at this air-code, you won't see any place where a class
returns a type that it didn't create, or exposed, as a property, a class.
The objects model the behavior of the system, not is data. Data comes along
for the ride. You will also notice that there is NO notion of a CPU or a
Monitor. Because the behavior of the system doesn't CARE that it is a CPU
or a Monitor.

This is with me trying my level best to come up with an example where I
would actually need to know that an item is a Monitor, but I can't figure
one.

I think in general, I don't bump into it when using "generic" classes,
like Point, or Stack, HashTable, or Button...or my own classes with that
sort of broad utility... I mean my form class will have a
Button GoButton,
Button NextButton,
Button ExitButton, etc...

It happens when I have to create a specific class for a very specific
peice of an application.

e.g. If I want a custom "ExitButton", I inherit a new class from
"Button" called "ExitButton"... and then I end up with

I assume it is because the ExitButton is intended to encapsulate the display
properties surrounding a button that the user should be able to look at and
say "Oh... that button will exit!" I also assume that you intend to put
this exit button on more than one form to make it reusable. There is both
something unique about that button that is different from other buttons, and
something reusable about this button that you want to encapsulate. It is
easy to justify creating the object.

In this case, however, there are not new methods or properties... just a new
constructor to justify the existence of this object. So, why is your
variable declared as type ExitButton? The class that uses the button
neither knows nor cares that it is an ExitButton. As far as that class is
concerned, it is a Button like any other. The only one that should know
that it is an exit button is the factory that creates it. Also, the name of
the button variable would be specific to its use.

Therefore, in the visible class, you could just as easily declare:

public MainForm : System.Windows.Forms.Form
{
// <note>You could use a factory instead, but I didn't for
clarity</note>
Button MainExitButton = new ExitButton();
// ...
}

Why did I call it MainExitButton? Because it is the exit button on the Main
form. This differentiates between the exit button that exists on ChildForm
and WarningDialog.

Even if the button isn't reusable... if it is specific to this form, then it
is still a MainExitButton, because it is a object of type ExitButton.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[42]

In article <L_*****************************************@comca st.com>,
ni*******@hotmail.nospam.com says...

Hi Dave

This is with me trying my level best to come up with an example where I
would actually need to know that an item is a Monitor, but I can't figure
one.

I found it amusing that you couldn't think of a scenario where we'd need
to know what the parts actually are, when its self evident. You need to
know what the parts of a computer are when you are modelling a computer.

E.g. After the user selects the components, and we've composed them into
a computer object, with motherboard, cpu, case, etc... the next logical
step will be to try and boot the thing up. ;)

MainProgram();

Computer myPC = new PC(Case, Motherboard, RAM, ...)
timer.Start;

try {
new myPC.Case.PushPowerButton();
}
catch {Exception SystemHalt)
timer.Stop;
Writeline("Dead after (seconds): "+timer.seconds.tostring));
Writeline(myPC.CPU.Temperature;)
Writeline(myPC.VideoCard.Temperature;)
...
}

Anyhow, I found your post quite insightful.

[Nick Malik [Microsoft]]

"42" <no****@nospam.com> wrote in message
news:MP************************@shawnews.vf.shawca ble.net...

In article <L_*****************************************@comca st.com>,
ni*******@hotmail.nospam.com says...

Hi Dave

This is with me trying my level best to come up with an example where I
would actually need to know that an item is a Monitor, but I can't figure
one.
I found it amusing that you couldn't think of a scenario where we'd need
to know what the parts actually are, when its self evident. You need to
know what the parts of a computer are when you are modelling a computer.

I'm not sure if I should be insulted by your insinuation or just amused at
the fact that you seem to have completely missed the point.

E.g. After the user selects the components, and we've composed them into
a computer object, with motherboard, cpu, case, etc... the next logical
step will be to try and boot the thing up. ;)

If you want to simulate a computer, you have little or no need to model the
parts. The BEHAVIOR of the parts, yes, but not the parts themselves,
because the parts are not pertinent to the BEHAVIOR of a computer.

Anyway, I'm signing off for a week. Either you get it or you don't. Good
luck.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[42]

In article <V7*****************************************@comca st.com>,
ni*******@hotmail.nospam.com says...

"42" <no****@nospam.com> wrote in message
news:MP************************@shawnews.vf.shawca ble.net...

In article <L_*****************************************@comca st.com>,
ni*******@hotmail.nospam.com says...

Hi Dave

This is with me trying my level best to come up with an example where I
would actually need to know that an item is a Monitor, but I can't figure
one.
I found it amusing that you couldn't think of a scenario where we'd need
to know what the parts actually are, when its self evident. You need to
know what the parts of a computer are when you are modelling a computer.

I'm not sure if I should be insulted by your insinuation or just amused at
the fact that you seem to have completely missed the point.

I wasn't insinuting anything. I don't think I missed the point either.

E.g. After the user selects the components, and we've composed them into
a computer object, with motherboard, cpu, case, etc... the next logical
step will be to try and boot the thing up. ;)

If you want to simulate a computer, you have little or no need to model the
parts.

In terms of modelling how they interact sure, your only interested in
the interfaces, and as long as the various parts implement the
interfaces it doesn't matter what they are. But in terms of actually
implementing the classes you would need to model the parts.

I guess your right insofar as the motherboard doesn't need to know its a
Monitor attached to it, as long as whatever it is implements the
IMonitor interface.
The BEHAVIOR of the parts, yes, but not the parts themselves,
because the parts are not pertinent to the BEHAVIOR of a computer. Anyway, I'm signing off for a week. Either you get it or you don't. Good
luck.

Take care.