Sub system protection

[Sharon]

Hi all.
To prevent access to a sub system internal types,
is it necessary to create the sub system in a different project,
and use the internal access level?
Or is there another way that will enable the creation of several sub systems
in the same project?
Thanks,
Sharon.

 

[justin creasy]

Could you please elaborate some on what is it you want to do? What
exactly do you mean by sub system, a different assembly, a different
thread? Please just give a brief description of what you are trying to
create.

 

[Sharon]

I want to create a sub system which will expose only a sub system facade.
I want all the sub system classes to be hidden inside the sub system.
The only way i know to do this, is to give the internal access level to each
class
in the sub system, except the facade, and compile it to a separate assembly.
The question is, is there a way for different sub systems to reside in the
same assembly
and yet for each sub system classes to be hidden inside their sub system.

 

[justin creasy]

I can think of two ideas right away that allow you to hide the details
of a class. Declaring variables and methods private will help to hide
them, and using different namespaces for classes also helps to seperate
them. I think what you want to do is use a different namespace for each
sub system, then methods in one sub system would not have public access
to attributes of another sub system. If this is not what you mean I'm
sorry, but I'm still a little confused on your goals. "sub system" is a
very ambiguous term.

 

[Sharon]

Hey Justin.
First, thanks for helping me out here.
Separating sub systems using different namespaces,
will not prevent one sub system from accessing another sub system classes.
Cause a sub system classes are not really hidden.

Below is the definition of a sub system.
It does not state that a sub system must be a "black box", but i want it to
be.

----------------------------------------------------------------------------------
A subsystem is a chunk of cohesive classes that can be compiled, linked, and
tested separately
Robert C. Martin gives three rules of thumb that may help to identify
subsystems:
To be cohesive, the classes in a [subsystem]
1. Must be closed together
2. Must be reused together
3. Should share a common function or policy
Classes are closed together, if a change to the application effects either
all or none of them.

 

[Michael C]

Hey Justin.
First, thanks for helping me out here.
Separating sub systems using different namespaces,
will not prevent one sub system from accessing another sub system classes.
Cause a sub system classes are not really hidden.

Afaik, all you can do (besides create a seperate dll) is create a private
class inside a class.

Michael