more class design question

[mp]

given that i'm in initial stage of design i'm pondering this option:
I have objects which are "cast stone"
there are different types, band, sill, header, medallion, capstone, etc
so I'm trying to envision if I should have one class CastStone with an
enum for type or have multiple classes which derive from CastStone or
ICastStone.

they each of course have similarities as well as differences. probably
no one but me can answer this but i thought i'd throw it out in case
there is something obvious to others who have been down this road before
in terms of making early design choices that simplify progress as
opposed to making things harder as the project progresses.

my naive assumption is that individual classes would eliminate a lot of
switch code in the CastStone object depending on the value of an enum,
even though the list of classes gets that much longer.

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

[Arne Vajhøj]

Post by mp
I have objects which are "cast stone"
there are different types, band, sill, header, medallion, capstone, etc
so I'm trying to envision if I should have one class CastStone with an
enum for type or have multiple classes which derive from CastStone or
ICastStone.
they each of course have similarities as well as differences. probably
no one but me can answer this but i thought i'd throw it out in case
there is something obvious to others who have been down this road before
in terms of making early design choices that simplify progress as
opposed to making things harder as the project progresses.
my naive assumption is that individual classes would eliminate a lot of
switch code in the CastStone object depending on the value of an enum,
even though the list of classes gets that much longer.

Exactly.

There is an old joke saying that OOP is switch free
programming.

And even though there certainly are valid cases for
switch in OOP, then the type enum and different behavior
based on value is very non-OOP'ish and should be
replaced with classes with the desired behavior.

Arne

[mp]

assumption is that individual classes would eliminate a lot of

Post by Arne Vajhøj

Post by mp
switch code in the CastStone object depending on the value of an enum,
even though the list of classes gets that much longer.

Exactly.
There is an old joke saying that OOP is switch free
programming.
And even though there certainly are valid cases for
switch in OOP, then the type enum and different behavior
based on value is very non-OOP'ish and should be
replaced with classes with the desired behavior.
Arne

thank you so much, have a great weekend

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

[Registered User]

Post by mp
I have objects which are "cast stone"
there are different types, band, sill, header, medallion, capstone, etc
so I'm trying to envision if I should have one class CastStone with an
enum for type or have multiple classes which derive from CastStone or
ICastStone.

The CastStone type/interface question reveals an aspect of BuildingComponent
types which hasn't been considered. There might be two types of
BuildingComponents: structural and decorative. A CastStone might be decorative
such as for a stone veneer or flooring. It also might be a cast pier or footing.

Post by mp
they each of course have similarities as well as differences. probably
no one but me can answer this but i thought i'd throw it out in case
there is something obvious to others who have been down this road before
in terms of making early design choices that simplify progress as
opposed to making things harder as the project progresses.

I have found design can benefit by writing throw-away code. Writing small pieces
of prototype code can reveal situations and conditions that have yet to be
considered. It's better to catch theses issues before actual coding begins.

Post by mp
my naive assumption is that individual classes would eliminate a lot of
switch code in the CastStone object depending on the value of an enum,
even though the list of classes gets that much longer.

Much depends on the specifics. Granularity can be good but excessive granularity
can create confusion. You have some ideas and now it might be a good idea to set
those thoughts aside. Approaching the problem from a different point of view can
reveal strengths and weaknesses in previous approaches.

You might consider looking at the problem from a contractor's POV. There will be
subcontractors who deal in specific subsets of construction such as foundation,
framing, finish carpentry, roofing, plumbing, electrical, heating & cooling etc.
All use building components but each uses more specific subsets of components.
Rather than using supertypes and subtypes for each of these, specifics distinct
namespaces might be a better organizational approach. Having everything based
upon a single supertype or interface may not be the best approach. Breaking the
problem down into smaller, more manageable pieces is not a bad idea.

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

[mp]

Post by Registered User
I have found design can benefit by writing throw-away code.

ha ha, everything i write is throw away :-)
but my brain loves trying to learn new things, even if it will never be
practical use...

Writing small pieces

Post by Registered User
of prototype code can reveal situations and conditions that have yet to be
considered. It's better to catch theses issues before actual coding begins.

that's what i thought i was doing in a way, trying to think thru the
interfaces and object patterns first without getting into the detail
code for the objects themselves. and keep making sure it will at least
build even if there's nothing to actually run yet...

Post by Registered User
Much depends on the specifics. Granularity can be good but excessive granularity
can create confusion. You have some ideas and now it might be a good idea to set
those thoughts aside. Approaching the problem from a different point of view can
reveal strengths and weaknesses in previous approaches.

There might be two types of
BuildingComponents: structural and decorative. A CastStone might be
decorative

yes in fact I have in my 'problem domain' (if that's the right term )
exactly that difference, structural and architectural. I'm only
designing a solution for the cast stone or precast industry so it's a
tiny microcosm of the entire industry you point out, carpentry etc.
in my context there are structural elements i only have to account for a
tiny fraction of the whole building where they are elements we use to
connect our products to, everything else can safely be ignored. and
those elements i only need to know size and location, very little other
information.

Post by Registered User
You might consider looking at the problem from a contractor's POV. There will be
subcontractors who deal in specific subsets of construction such as foundation,
framing, finish carpentry, roofing, plumbing, electrical, heating & cooling etc.
All use building components but each uses more specific subsets of components.
Rather than using supertypes and subtypes for each of these, specifics distinct
namespaces might be a better organizational approach. Having everything based
upon a single supertype or interface may not be the best approach. Breaking the
problem down into smaller, more manageable pieces is not a bad idea.

my names do indeed indicate a much broader problem than the one i'm
actually working on...building component implies, as you note, every
possible part of a whole building, i might change that, and allow for
the (very theoretical) possiblilty that the domain could include all
parts rather than the one tiny part i'm looking at.
an i'll look into namespaces and how one can have more than one in a
project, that was always just what came up when i started a project, i
haven't read much about namespaces themselves.

thanks as always for your thoughtful responses


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

[mp]

All use building components but each uses more specific subsets of
components.

Post by Registered User
Rather than using supertypes and subtypes for each of these, specifics distinct
namespaces might be a better organizational approach. Having everything based
upon a single supertype or interface may not be the best approach. Breaking the
problem down into smaller, more manageable pieces is not a bad idea.

---

so you're suggesting something like
namespace BuildingProject
nestednamespace Strucural
nestednamespace Architectural

etc>?

as a way of organizing code into different sections?

for example in my 'program' i create a block of stone
then that block will 'draw itself' into a cad program

so the accessing of the cad program is an entirely separate part of what
i need to do and as yet i haven't started that part of the design.

would i then do
namespace CreateBuildingObjects
namespace InteractWithCad

then an object in CreateBuildingObjects could call to a method in
InteractWithCad to draw itself?

can namespaces live in different projects and then work together in a
'main' project (so as to have fewer classes to have to look at in the
solutioon explorer) as a way to divide different operations in the program?



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