CSharp Class Design Issue

  • Thread starter Thread starter Sunny
  • Start date Start date
S

Sunny

Hi All,
I have a serious issue regarding classes scope and
visibility. In my application, i have a class
name "TextFile", and also a few other classes
like "TotalWords", "TotalLines" and etc.., which are
suppose to describe the structure of my main TextFile
class. Also i have created some custom collection classes,
which only take items of the types, they are designed for.
Now the problem is that I want my element classes,
like "TotalWords", "TotalLines" to be visible only to the
children of my main, "TextFile" class, that is once i
create an instance of a "TextFile" class should these
other classes be visible, to create details of a TextFile.
Where in my code should i place these classes and also
their collection (wrapper classes).
The main problem i am facing is that, my Collections are
getting incremented multiple times, and i am in a big wreck

Thanks in Advance for any consideration
With Regards! Sunny
 
Sunny,

You can not say that a whole class is only visible to a particular
class. If anything, the best you can do is declare your other classes as
internal and make sure that they are defined in the same place as the
TextFile class. This way, only classes in the assembly can see that class
(including your TextFile class).

Hope this helps.
 
See, this does not solves my prob, alone, also
The concept does not makes sense either, see, there is no
point of having like this

TextFile.Comment() (Does not makes sense, as y one would
need this)

TextFile aFile = new TextFile(Name, loc, ..) (Looks good)
Now, this one would make sense
aFile.Comment() = new Comment().... (since here u would
need them)

But how to do it like this, that is make Comments() class
visible only to children of TextFile().....
The problem is still there .....

With Regards
Sunny
-----Original Message-----
Sunny,

You can not say that a whole class is only visible to a particular
class. If anything, the best you can do is declare your other classes as
internal and make sure that they are defined in the same place as the
TextFile class. This way, only classes in the assembly can see that class
(including your TextFile class).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Sunny said:
Hi All,
I have a serious issue regarding classes scope and
visibility. In my application, i have a class
name "TextFile", and also a few other classes
like "TotalWords", "TotalLines" and etc.., which are
suppose to describe the structure of my main TextFile
class. Also i have created some custom collection classes,
which only take items of the types, they are designed for.
Now the problem is that I want my element classes,
like "TotalWords", "TotalLines" to be visible only to the
children of my main, "TextFile" class, that is once i
create an instance of a "TextFile" class should these
other classes be visible, to create details of a TextFile.
Where in my code should i place these classes and also
their collection (wrapper classes).
The main problem i am facing is that, my Collections are
getting incremented multiple times, and i am in a big wreck

Thanks in Advance for any consideration
With Regards! Sunny
Click to expand...


.
Click to expand...
 
Sunny,

I'm not quite sure what you are trying to do. The following is not
correct syntax:

aFile.Comment() = new Comment()

You can not assign an object to a method (that is what the parenthesis
at the end of Comment mean).

You can not make a class visible only to another class. The lowest
level you can go is make the class accessible to other classes in the same
assembly, using the internal keyword.

Now if you don't want the Comment property/method to be exposed to
anyone but children of the TextFile class, then you can set the
accessibility of that to protected, and only itself and derived members will
be able to access it.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Sunny said:
See, this does not solves my prob, alone, also
The concept does not makes sense either, see, there is no
point of having like this

TextFile.Comment() (Does not makes sense, as y one would
need this)

TextFile aFile = new TextFile(Name, loc, ..) (Looks good)
Now, this one would make sense
aFile.Comment() = new Comment().... (since here u would
need them)

But how to do it like this, that is make Comments() class
visible only to children of TextFile().....
The problem is still there .....

With Regards
Sunny
-----Original Message-----
Sunny,

You can not say that a whole class is only visible to a particular
class. If anything, the best you can do is declare your other classes as
internal and make sure that they are defined in the same place as the
TextFile class. This way, only classes in the assembly can see that class
(including your TextFile class).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Sunny said:
Hi All,
I have a serious issue regarding classes scope and
visibility. In my application, i have a class
name "TextFile", and also a few other classes
like "TotalWords", "TotalLines" and etc.., which are
suppose to describe the structure of my main TextFile
class. Also i have created some custom collection classes,
which only take items of the types, they are designed for.
Now the problem is that I want my element classes,
like "TotalWords", "TotalLines" to be visible only to the
children of my main, "TextFile" class, that is once i
create an instance of a "TextFile" class should these
other classes be visible, to create details of a TextFile.
Where in my code should i place these classes and also
their collection (wrapper classes).
The main problem i am facing is that, my Collections are
getting incremented multiple times, and i am in a big wreck

Thanks in Advance for any consideration
With Regards! Sunny
Click to expand...


.
Click to expand...
Click to expand...
 
Hi Nicholas,

message
You can not make a class visible only to another class.
Click to expand...
<snip>

Well you can declare an inner class private to an outer class:

public class Foo
{
...
private class Bar
{
...
}
...
}

On the other hand, I'm guessing from Sunny's post that this isn't
exactly what he wants to do since a private inner class cannot be exposed
through the public interface of the outer class.

Sunny, you are creating a set of classes to be used by others, yes? Are
the set of classes you are creating going to be in a seperate assembly?

Regards,
Dan
 
Your overall intent is very unclear to me as well. Things like "TotalWords"
and "TotalLines" don't sound to me like class names but rather properties of
the TextFile class. What do those "classes" do exactly. They seem, by name
and by your description, to expose functionality explicitly linked to the
TextFile class, in which case it seems to me at the very least the TextFile
should use composition to contain/expose them. In that case marking them
internal seems to solve the problem of nobody "accidentally" using them
directly.

If you expose collection classes via the main class (TextFile) then you
would have something like
TextFile aFile = new TextFile(blah blah);
aFile.Comments.Add(new Comment(blah blah));

not

aFile.Comment() = new Comment();


Sunny said:
See, this does not solves my prob, alone, also
The concept does not makes sense either, see, there is no
point of having like this

TextFile.Comment() (Does not makes sense, as y one would
need this)

TextFile aFile = new TextFile(Name, loc, ..) (Looks good)
Now, this one would make sense
aFile.Comment() = new Comment().... (since here u would
need them)

But how to do it like this, that is make Comments() class
visible only to children of TextFile().....
The problem is still there .....

With Regards
Sunny
-----Original Message-----
Sunny,

You can not say that a whole class is only visible to a particular
class. If anything, the best you can do is declare your other classes as
internal and make sure that they are defined in the same place as the
TextFile class. This way, only classes in the assembly can see that class
(including your TextFile class).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Sunny said:
Hi All,
I have a serious issue regarding classes scope and
visibility. In my application, i have a class
name "TextFile", and also a few other classes
like "TotalWords", "TotalLines" and etc.., which are
suppose to describe the structure of my main TextFile
class. Also i have created some custom collection classes,
which only take items of the types, they are designed for.
Now the problem is that I want my element classes,
like "TotalWords", "TotalLines" to be visible only to the
children of my main, "TextFile" class, that is once i
create an instance of a "TextFile" class should these
other classes be visible, to create details of a TextFile.
Where in my code should i place these classes and also
their collection (wrapper classes).
The main problem i am facing is that, my Collections are
getting incremented multiple times, and i am in a big wreck

Thanks in Advance for any consideration
With Regards! Sunny
Click to expand...


.
Click to expand...
Click to expand...
 
Sunny,

Perhaps you should consider using the singleton pattern for those
classes in which you do not want multiple instances to occur. You
might also think about embedding some of the classes within other
parent classes -- this would by default define the scope of the
embedded class.
 
oh ok i am sorry for this lemme right this thing again.
see

this is what i wanted
TextFile aFile = new TextFile("NameofFile", 23, 24)..
now remember my comment() class, i wanted to make it
visible only to this newly created object, like

aFile.comment() aComm = new comment("asap", "Fullcomment");
now adding this to my comments collection only for the
aFile object...
(so this is what i want to do now)
aFile.commColl.Add(aComm); now if i need to acces it,..
aFile.commColl.Item(ind)... and i will get aComm at the pos

The whole problem started some days back, when multiple
Objects of TextFile class were getting generated in loops,
and they were suppose to create comments for themselves
only, and not for the parent TextFile class, at the end of
the day, when i looked at the collections class for one
Textfile (object), i found multiple entries for it... and
everything is downhil since then, the servers went out and
hell broke loose...

Maybe this is not doable, or maybe perfection is too much
to ask for......

I really appreciate all your help, you are all great people

-----Original Message-----
Sunny,

I'm not quite sure what you are trying to do. The following is not
correct syntax:

aFile.Comment() = new Comment()

You can not assign an object to a method (that is what the parenthesis
at the end of Comment mean).

You can not make a class visible only to another class. The lowest
level you can go is make the class accessible to other classes in the same
assembly, using the internal keyword.

Now if you don't want the Comment property/method to be exposed to
anyone but children of the TextFile class, then you can set the
accessibility of that to protected, and only itself and derived members will
be able to access it.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Sunny said:
See, this does not solves my prob, alone, also
The concept does not makes sense either, see, there is no
point of having like this

TextFile.Comment() (Does not makes sense, as y one would
need this)

TextFile aFile = new TextFile(Name, loc, ..) (Looks good)
Now, this one would make sense
aFile.Comment() = new Comment().... (since here u would
need them)

But how to do it like this, that is make Comments() class
visible only to children of TextFile().....
The problem is still there .....

With Regards
Sunny
-----Original Message-----
Sunny,

You can not say that a whole class is only visible
Click to expand...
to
a particular
class. If anything, the best you can do is declare
Click to expand...
your
other classes as
internal and make sure that they are defined in the
Click to expand...
same
place as the
TextFile class. This way, only classes in the assembly can see that class
(including your TextFile class).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Hi All,
I have a serious issue regarding classes scope and
visibility. In my application, i have a class
name "TextFile", and also a few other classes
like "TotalWords", "TotalLines" and etc.., which are
suppose to describe the structure of my main TextFile
class. Also i have created some custom collection classes,
which only take items of the types, they are designed for.
Now the problem is that I want my element classes,
like "TotalWords", "TotalLines" to be visible only to the
children of my main, "TextFile" class, that is once i
create an instance of a "TextFile" class should these
other classes be visible, to create details of a TextFile.
Where in my code should i place these classes and also
their collection (wrapper classes).
The main problem i am facing is that, my Collections are
getting incremented multiple times, and i am in a big wreck

Thanks in Advance for any consideration
With Regards! Sunny


.
Click to expand...
Click to expand...


.
Click to expand...
 
Sunny said:
See, this does not solves my prob, alone, also
The concept does not makes sense either, see,
there is no point of having like this

TextFile.Comment() (Does not makes sense, as y one
would need this)

TextFile aFile = new TextFile(Name, loc, ..) (Looks good)
Now, this one would make sense
aFile.Comment() = new Comment().... (since here u would
need them)

But how to do it like this, that is make Comments() class
visible only to children of TextFile().....
The problem is still there .....
Click to expand...

The classes you've mentioned [in this, and your earlier post]:

* TotalWords
* TotalLines
* Comment

model concepts which only have meaning within the context of a TextFile
class. Given this, it does not seem appropriate to either:

* Model them as classes [in the case of TotalWords and
TotalLines], or to

* Model them as separate classes even if, as suggested, they
are declared in the same assembly for purposes of restricting
visibility

Instead, a possibly more appropriate approach might be to model these as
attributes [fields / members] of TextFile. One approach might be to model
them as properties, and provide suitable getter / setters:

* Model TotalLines and TotalWords as integer-types
* Comment could might simply be a String-type

The reason this is suggested is that there seems to be little 'intelligence'
in these items - the suggested existing types would appear to provide the
necessary basic behaviour. You would, generally, only use classes where more
sophisticated behaviour was required.

Of course it may be that these items *may* need to exhibit more
sophisticated behaviour, in which case it makes sense to model them as
classes. For example, TotalLines might perform some sort of validation [e.g.
throw an execption if there are zero lines ?], or Comment might be an
example of a more general class that might be used throughout your
application, or even other applications, in which case you'd want to make it
part of a library / collection of general-purpose classes.

However, with TotalLines and TotalWords, the issue of context remains: these
classes make no sense by themselves. For example, of what use could an
instance of TotalLines be without its 'parent' TextFile object ? Modelling
TotalLines as a top-level class encourages such things [even if you do
things to restrict visisbility like marking them 'internal' within an
asembly, or things to better manage them like enclosing them [along with
TextFile] in a separate namespace.

An approach allowing you to implement these items as classes, whilst
restricting visibility, and maintaining context, is to model them as
'private' nested classes. In this way:

* TextFile controls all aspects of these items, from the
number of instances, to the method calls made

* TextFile controls the release of data / method return
values from these objects

Thus, it would be possible to create sophisticated classes for TextFile's
exclusive use, but have the outside world only see what TextFile chooses to
have revealed all without danger of the classes being used in an
inapproapriate way [which can still happen if they are top-level classes in
an assembly].

Finally, since it is not known what your actual class design requirements
are, please take this message as no more than a source of possible ideas to
explore. It is certainly true there are often several ways to implement a
design - having several options available allows you to carefully craft an
appropriate solution to the problem at hand.

I hope this helps.

Anthony Borla
 
I understand what your explanation of totallines and
totalwords, they are not classes.... mymistake of morning

the total classes are like this, all of them
textfile(), comment(), variable(), macro(), statement()
also there are collection classes (wrappers) for all of
the above, that take only objects of the one they are
designed for, now.....

see this is what i think should happen, i should only be
able to create objects of comment, or variable or macro..
from one of the instances of textfile class, and not from
the textfile class, (textfile.comment acom = new comment
(..)) (there is no reason for making it like this)

This is what i think should happen
textfile aFile = new textfile(.......)
and now
aFile.comment acom = new comment(...), and then adding
this comment to the collection of aFile's comments
collection only, and only

afile.comColl.Add(acom), and then can be accessed as

textfile.filesColl.Item(i).comColl.item(the one i entered)


With Regards
Sunny


-----Original Message-----

Sunny said:
See, this does not solves my prob, alone, also
The concept does not makes sense either, see,
there is no point of having like this

TextFile.Comment() (Does not makes sense, as y one
would need this)

TextFile aFile = new TextFile(Name, loc, ..) (Looks good)
Now, this one would make sense
aFile.Comment() = new Comment().... (since here u would
need them)

But how to do it like this, that is make Comments() class
visible only to children of TextFile().....
The problem is still there .....
Click to expand...

The classes you've mentioned [in this, and your earlier post]:

* TotalWords
* TotalLines
* Comment

model concepts which only have meaning within the context of a TextFile
class. Given this, it does not seem appropriate to either:

* Model them as classes [in the case of TotalWords and
TotalLines], or to

* Model them as separate classes even if, as suggested, they
are declared in the same assembly for purposes of restricting
visibility

Instead, a possibly more appropriate approach might be to model these as
attributes [fields / members] of TextFile. One approach might be to model
them as properties, and provide suitable getter / setters:

* Model TotalLines and TotalWords as integer-types
* Comment could might simply be a String-type

The reason this is suggested is that there seems to be little 'intelligence'
in these items - the suggested existing types would appear to provide the
necessary basic behaviour. You would, generally, only use classes where more
sophisticated behaviour was required.

Of course it may be that these items *may* need to exhibit more
sophisticated behaviour, in which case it makes sense to model them as
classes. For example, TotalLines might perform some sort of validation [e.g.
throw an execption if there are zero lines ?], or Comment might be an
example of a more general class that might be used throughout your
application, or even other applications, in which case you'd want to make it
part of a library / collection of general-purpose classes.

However, with TotalLines and TotalWords, the issue of context remains: these
classes make no sense by themselves. For example, of what use could an
instance of TotalLines be without its 'parent' TextFile object ? Modelling
TotalLines as a top-level class encourages such things [even if you do
things to restrict visisbility like marking them 'internal' within an
asembly, or things to better manage them like enclosing them [along with
TextFile] in a separate namespace.

An approach allowing you to implement these items as classes, whilst
restricting visibility, and maintaining context, is to model them as
'private' nested classes. In this way:

* TextFile controls all aspects of these items, from the
number of instances, to the method calls made

* TextFile controls the release of data / method return
values from these objects

Thus, it would be possible to create sophisticated classes for TextFile's
exclusive use, but have the outside world only see what TextFile chooses to
have revealed all without danger of the classes being used in an
inapproapriate way [which can still happen if they are top-level classes in
an assembly].

Finally, since it is not known what your actual class design requirements
are, please take this message as no more than a source of possible ideas to
explore. It is certainly true there are often several ways to implement a
design - having several options available allows you to carefully craft an
appropriate solution to the problem at hand.

I hope this helps.

Anthony Borla


.
Click to expand...
 
Sunny said:
oh ok i am sorry for this lemme right this thing again.
see

this is what i wanted
TextFile aFile = new TextFile("NameofFile", 23, 24)..
now remember my comment() class, i wanted to make it
visible only to this newly created object, like

aFile.comment() aComm = new comment("asap", "Fullcomment");
now adding this to my comments collection only for the
aFile object...
(so this is what i want to do now)
aFile.commColl.Add(aComm); now if i need to acces it,..
aFile.commColl.Item(ind)... and i will get aComm at the pos

The whole problem started some days back, when multiple
Objects of TextFile class were getting generated in loops,
and they were suppose to create comments for themselves
only, and not for the parent TextFile class, at the end of
the day, when i looked at the collections class for one
Textfile (object), i found multiple entries for it... and
everything is downhil since then, the servers went out and
hell broke loose...

Maybe this is not doable, or maybe perfection is too much
to ask for......

I really appreciate all your help, you are all great people
Click to expand...

Ok, from your description Comment is a top-level class, so it is usable by
any classes requiring its services. Correct ?

Also, it looks as if each TextFile object owns a collection of such objects,
thus it may have zero, or more such objects. Correct ?

The problem, though, is that duplicate Comment objects exist in a TextFile
object's Comment-collection, and you wish to find a way to distinguish
between them, perhaps avoiding the addition of duplicate Comment objects in
the first place. Correct ?

If all the above is true, then your problem appears to be one of ensuring
each Comment object can be uniquely identified within the context in which
it appears. In other words:

* If a Comment object may only belong to a single
TextFile objet's collection [which appears to be the
case], then you could identify each such object with
a timestamp, or even just on the 'comment text' it
contains [assuming duplicate text is unlikely]

* If a Comment objects from different TextFile objects
can reside in the same collection then more effort into
ensuring unique identity has to be made. You could, in
addition to any timestamp information, also include the
owning object's identifer [it's filename / path may well
suffice in this role ?]

Anyway, to cut a long story short, if this is indeed your problem, you'll
want to expand your comment class to include some sort of identifier
attribute(s) as described above. Post again if needing more details.

I hope this helps.

Anthony Borla
 
Sunny said:
I understand what your explanation of totallines and
totalwords, they are not classes.... mymistake of morning
Click to expand...
This is what i think should happen
textfile aFile = new textfile(.......)
and now
aFile.comment acom = new comment(...), and then adding
this comment to the collection of aFile's comments
collection only, and only

afile.comColl.Add(acom), and then can be accessed as

textfile.filesColl.Item(i).comColl.item(the one i entered)
Click to expand...

See my response to your other message. It *sounds* as if it is an object
identity issue, though you will have to investigate this further.

Cheers,

Anthony Borla
 
Back
Top