advice on class design

[mp]

trying layout overall architecture of a c# program
total newb c# and novice hobbiest any programing for that matter

upper level class cBuildingComponent
of which there are many kinds like
cStone : cBuildingComponent
cSteelBeam : cBuildingComponent

each element will have various properties like size weight color etc
and methods such as Draw

some properties will apply more to some elements than others
eg color might apply to a stone but not a steel beam

do i put the properties/methods in the base class with no code then each
subclass has code for that property?

a pointer to example for learning would be super, and any thoughts
appreciated


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Luuk]

Post by mp
trying layout overall architecture of a c# program
total newb c# and novice hobbiest any programing for that matter
upper level class cBuildingComponent
of which there are many kinds like
cStone : cBuildingComponent
cSteelBeam : cBuildingComponent
each element will have various properties like size weight color etc
and methods such as Draw
some properties will apply more to some elements than others
eg color might apply to a stone but not a steel beam
do i put the properties/methods in the base class with no code then each
subclass has code for that property?
a pointer to example for learning would be super, and any thoughts
appreciated

I think it depends on what should happen if you need the color of steel.

I think defining them in the base class, and possibly overriding them in
a subclass is the best option.

(but i'm not an exprt in C# (yet) too)

One example from this place:
https://msdn.microsoft.com/en-us/library/ebca9ah3.aspx

It could be hard to implement the propery 'Area' for the baseclass
'ShapesClass', while it seems simple for the object 'Square'

[Registered User]

You might consider using segregating similar properties into Interfaces.

interface IBuildingComponent
{
// methods and properties common to all types of building components
}

interface IStoneBuildingComponent
{
// methods and properties specific to stone components
}

interface IBeamBuildingComponent
{
// methods and properties specific to beam components
}

class SteelBeam : IBuildingComponent, IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}

class LaminatedDimensionalLumberBeam : IBuildingComponent,
IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}

class Granite : IBuildingComponent, IStoneBuildingComponent
{
// implements IBuildingComponent and IStoneBuildingComponent

}

class Marble : IBuildingComponent, IStone
{
// implements IBuildingComponent and IStoneBuildingComponent

}

Depending upon your needs you might implement IStoneBuildingComponent and
IBeamBuildingComponent
as their own types and use aggregation e.g.

class Stone : IStoneBuildingComponent
{
...
}

class Marble : IBuildingComponent, IStone
{
// implements IBuildingComponent
IStone stone = new Stone();
// implement IStone using Stone implementation of IStone
public <type> SomeIStoneMethod(<args>)
{
return stone,SomeIStoneMethod(<args>);
}
}

Post by mp
trying layout overall architecture of a c# program
total newb c# and novice hobbiest any programing for that matter
upper level class cBuildingComponent
of which there are many kinds like
cStone : cBuildingComponent
cSteelBeam : cBuildingComponent
each element will have various properties like size weight color etc
and methods such as Draw
some properties will apply more to some elements than others
eg color might apply to a stone but not a steel beam
do i put the properties/methods in the base class with no code then each
subclass has code for that property?
a pointer to example for learning would be super, and any thoughts
appreciated
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Arne Vajhøj]

Post by Registered User
You might consider using segregating similar properties into Interfaces.
interface IBuildingComponent
{
// methods and properties common to all types of building components
}
interface IStoneBuildingComponent
{
// methods and properties specific to stone components
}
interface IBeamBuildingComponent
{
// methods and properties specific to beam components
}
class SteelBeam : IBuildingComponent, IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}
class LaminatedDimensionalLumberBeam : IBuildingComponent,
IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}
class Granite : IBuildingComponent, IStoneBuildingComponent
{
// implements IBuildingComponent and IStoneBuildingComponent
}
class Marble : IBuildingComponent, IStone
{
// implements IBuildingComponent and IStoneBuildingComponent
}

I would let IStoneBuildingComponent and IBeamBuildingComponent
extend IBuildingComponent.

Arne

[mp]

Post by Arne Vajhøj

Post by Registered User
You might consider using segregating similar properties into Interfaces.
interface IBuildingComponent
{
// methods and properties common to all types of building components
}
interface IStoneBuildingComponent
{
// methods and properties specific to stone components
}
interface IBeamBuildingComponent
{
// methods and properties specific to beam components
}
class SteelBeam : IBuildingComponent, IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}
class LaminatedDimensionalLumberBeam : IBuildingComponent,
IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}
class Granite : IBuildingComponent, IStoneBuildingComponent
{
// implements IBuildingComponent and IStoneBuildingComponent
}
class Marble : IBuildingComponent, IStone
{
// implements IBuildingComponent and IStoneBuildingComponent
}

I would let IStoneBuildingComponent and IBeamBuildingComponent
extend IBuildingComponent.
Arne

Thanks to all for your thoughts, gives me direction to study.
so Arne, you agree interfaces better than inheritance?

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Arne Vajhøj]

Post by mp

Post by Arne Vajhøj

Post by Registered User
You might consider using segregating similar properties into Interfaces.
interface IBuildingComponent
{
// methods and properties common to all types of building components
}
interface IStoneBuildingComponent
{
// methods and properties specific to stone components
}
interface IBeamBuildingComponent
{
// methods and properties specific to beam components
}
class SteelBeam : IBuildingComponent, IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}
class LaminatedDimensionalLumberBeam : IBuildingComponent,
IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}
class Granite : IBuildingComponent, IStoneBuildingComponent
{
// implements IBuildingComponent and IStoneBuildingComponent
}
class Marble : IBuildingComponent, IStone
{
// implements IBuildingComponent and IStoneBuildingComponent
}

I would let IStoneBuildingComponent and IBeamBuildingComponent
extend IBuildingComponent.

Thanks to all for your thoughts, gives me direction to study.
so Arne, you agree interfaces better than inheritance?

Interfaces is fine.

I just want to have interface inherit from other interface
to ensure consistency.

Arne

[mp]

Post by Arne Vajhøj

Post by mp

Post by Arne Vajhøj

Post by Registered User
You might consider using segregating similar properties into Interfaces.
interface IBuildingComponent
{
// methods and properties common to all types of building components
}
<snip>

I would let IStoneBuildingComponent and IBeamBuildingComponent
extend IBuildingComponent.

Thanks to all for your thoughts, gives me direction to study.
so Arne, you agree interfaces better than inheritance?

Interfaces is fine.
I just want to have interface inherit from other interface
to ensure consistency.
Arne

from what i've been reading inheritance is used in "is a" cases
here's something i came across
<quote>
For answers to questions like this, I often turn to the .NET Framework
Design Guidelines, which have this to say about choosing between classes
and interfaces
Their general recommendations are as follows:

Do favor defining classes over interfaces.
Do use abstract classes instead of interfaces to decouple the
contract from implementations. Abstract classes, if defined correctly,
allow for the same degree of decoupling between contract and implementation.
Do define an interface if you need to provide a polymorphic
hierarchy of value types.
Consider defining interfaces to achieve a similar effect to that of
multiple inheritance.
<quote>

in the context of that, can you explain why your interface
recommendations are better than inheritance in this case?

thanks so much for your time and insights

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Arne Vajhøj]

Post by mp

Post by Arne Vajhøj

Post by mp

Post by Arne Vajhøj

Post by Registered User
You might consider using segregating similar properties into Interfaces.
interface IBuildingComponent
{
// methods and properties common to all types of building components
}
<snip>

I would let IStoneBuildingComponent and IBeamBuildingComponent
extend IBuildingComponent.

Thanks to all for your thoughts, gives me direction to study.
so Arne, you agree interfaces better than inheritance?

Interfaces is fine.
I just want to have interface inherit from other interface
to ensure consistency.

from what i've been reading inheritance is used in "is a" cases
here's something i came across
<quote>
For answers to questions like this, I often turn to the .NET Framework
Design Guidelines, which have this to say about choosing between classes
and interfaces
Do favor defining classes over interfaces.
Do use abstract classes instead of interfaces to decouple the
contract from implementations. Abstract classes, if defined correctly,
allow for the same degree of decoupling between contract and
implementation.
Do define an interface if you need to provide a polymorphic
hierarchy of value types.
Consider defining interfaces to achieve a similar effect to that of
multiple inheritance.
<quote>
in the context of that, can you explain why your interface
recommendations are better than inheritance in this case?

They have relaxed that wording a bit in newer .NET versions.

Latest:

https://msdn.microsoft.com/en-us/library/ms229022(v=vs.110).aspx

VS 2010/.NET 4.0:

https://msdn.microsoft.com/en-us/library/ms229022(v=vs.100).aspx

I don't agree with that recommendation.

They have a point that it is easier to add methods to an abstract
class than to an interface *IF* it is a library used by many
independent developers.

But first note that the reason do not apply to interfaces
with a much narrower usage.

Second there are drawbacks from using abstract class as
only one class can be inherited.

Third there are workarounds for the interface problem:
- do like Microsoft does and use extension methods on
interfaces
- have version extending interfaces

I don't think you should worry about this.

Arne

[Registered User]

You are correct Arne. I failed to double my psuedo code.

Post by Arne Vajhøj

Post by Registered User
You might consider using segregating similar properties into Interfaces.
interface IBuildingComponent
{
// methods and properties common to all types of building components
}
interface IStoneBuildingComponent
{
// methods and properties specific to stone components
}
interface IBeamBuildingComponent
{
// methods and properties specific to beam components
}
class SteelBeam : IBuildingComponent, IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}
class LaminatedDimensionalLumberBeam : IBuildingComponent,
IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}
class Granite : IBuildingComponent, IStoneBuildingComponent
{
// implements IBuildingComponent and IStoneBuildingComponent
}
class Marble : IBuildingComponent, IStone
{
// implements IBuildingComponent and IStoneBuildingComponent
}

I would let IStoneBuildingComponent and IBeamBuildingComponent
extend IBuildingComponent.
Arne

[mp]

Post by Arne Vajhøj

Post by Registered User
You might consider using segregating similar properties into Interfaces.
interface IBuildingComponent
{
// methods and properties common to all types of building components
}
interface IStoneBuildingComponent
{
// methods and properties specific to stone components
}
interface IBeamBuildingComponent
{
// methods and properties specific to beam components
}
class SteelBeam : IBuildingComponent, IBeamBuildingComponent
{
// implements IBuildingComponent and IBeamBuildingComponent
}

I would let IStoneBuildingComponent and IBeamBuildingComponent
extend IBuildingComponent.
Arne

Arne, is this what you mean?

interface IStoneBuildingComponent : IBuildingComponent
interface IBeamBuildingComponent : IBuildingComponent

then the other above defs would be like
class SteelBeam : IBeamBuildingComponent
instead of
class SteelBeam : IBuildingComponent, IBeamBuildingComponent

is that right?
so "extends" is basically the "same" as "inherits from " ?
("same" other than all the differnces betw interface and class)

IBasicInterface
IExtendedInterface : IBasicInterface

BasicClass
ExtendedClass : BasicClass


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[mp]

Post by mp

Post by Arne Vajhøj
I would let IStoneBuildingComponent and IBeamBuildingComponent
extend IBuildingComponent.
Arne

Arne, is this what you mean?
interface IStoneBuildingComponent : IBuildingComponent
interface IBeamBuildingComponent : IBuildingComponent
then the other above defs would be like
class SteelBeam : IBeamBuildingComponent
instead of
class SteelBeam : IBuildingComponent, IBeamBuildingComponent
is that right?
so "extends" is basically the "same" as "inherits from " ?
("same" other than all the differnces betw interface and class)
IBasicInterface
IExtendedInterface : IBasicInterface
BasicClass
ExtendedClass : BasicClass

looking at other documentation i find this example

IBasicInterface
IExtendedInterface extends IBasicInterface

searching for explanation of difference between
IExtendedInterface : IBasicInterface
and
IExtendedInterface extends IBasicInterface
but haven't found so far, still searching tho

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Arne Vajhøj]

Post by mp
searching for explanation of difference between
IExtendedInterface : IBasicInterface
and
IExtendedInterface extends IBasicInterface
but haven't found so far, still searching tho

The first is C# - the second is Java.

:-)

Arne

[Arne Vajhøj]

On 12/14/2016 11:35 AM, mp wrote:
is this what you mean?

Post by mp
interface IStoneBuildingComponent : IBuildingComponent
interface IBeamBuildingComponent : IBuildingComponent
then the other above defs would be like
class SteelBeam : IBeamBuildingComponent
instead of
class SteelBeam : IBuildingComponent, IBeamBuildingComponent
is that right?

Yes - I think enforcing that an IXxxxBuildingComponent is an
IBuildingComponent is a good thing.

Which of the to class definitions are used is less important
as they will have the exact same meaning in this case.

Post by mp
so "extends" is basically the "same" as "inherits from " ?
("same" other than all the differnces betw interface and class)
IBasicInterface
IExtendedInterface : IBasicInterface
BasicClass
ExtendedClass : BasicClass

That is probably just a java'ism on my part.

In C# it is:

interface I1
class C1
interface I2 : I1
class C2 : C1
class C2 : I1

But in Java it is:

interface I1
class C1
interface I2 extends I1
class C2 extends C1
class C2 implements I1

Arne

[mp]

Post by mp
is this what you mean?

Post by mp
interface IStoneBuildingComponent : IBuildingComponent
interface IBeamBuildingComponent : IBuildingComponent
<snip>

Yes - I think enforcing that an IXxxxBuildingComponent is an
IBuildingComponent is a good thing.
<snip>
Arne

Thank you again.
I may be overusing the idea that everything in my program is a "kind of"
building component
at this point i have (once i change everything over to interface)
IBuildingComponent

IBuildingComponentMaterial : IBuildingComponent
IBuildingComponentStructural : IBuildingComponentMaterial
IBuildingComponentArchitectural : IBuildingComponentMaterial
IBuildingComponentSteelBeam : IBuildingComponentStructural
IBuildingComponentCastStone : IBuildingComponentArchitectural
...etc...
//the physical objects that have size, weight, volume, etc properties

IBuildingComponentGraphical : IBuildingComponent
//the graphical representation of things in a drawing of the objects

//this one i'm especially questionable about being a "kind of"
//it's more of an "attribute of" ???
IBuildingComponentNominal : IBuildingComponent
//names for
everything(partnames,colornames,filenames,drawingnames,layernames,linetypenames,blocknames,sheetnames,viewnames
that will be associated with any object that can draw itself in a
drawing program)

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus