is this a reasonable design?

[mp]

...the context here i think is clear from my many recent posts
(even tho the info here would otherwise be too sparce)

ICastStone
IView
ICad

CastStone : ICastStone
{
//property
IView View{get;set;}
...}

View : IView
{
//property
ICad Cad {get;set;}
//method
Draw(){this.Cad.Draw}

Cad : ICad
{//knows about cad drawing...}

...then
CastStone.View.Draw

does it seem like adequate separation of responsibilities?

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

[Arne Vajhøj]

Post by mp
...the context here i think is clear from my many recent posts
(even tho the info here would otherwise be too sparce)
ICastStone
IView
ICad
CastStone : ICastStone
{
//property
IView View{get;set;}
...}
View : IView
{
//property
ICad Cad {get;set;}
//method
Draw(){this.Cad.Draw}
Cad : ICad
{//knows about cad drawing...}
...then
CastStone.View.Draw
does it seem like adequate separation of responsibilities?

I assume that the properties shown are part of the interfaces.

It is certainly one way of doing it.

Probably very well aligned with original ideas about OOP.

I would do it differently though.

I would build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.

I would also consider whether:

(I)View has a (i)Cad is the correct model of the
real world or if you instead want:

interface IView
interface ScreenView : IView
interface CadView : IView

But I know too little about CAD to be sure.

Arne

[mp]

Post by Arne Vajhøj

Post by mp
...then
CastStone.View.Draw
does it seem like adequate separation of responsibilities?

I assume that the properties shown are part of the interfaces.
It is certainly one way of doing it.
Probably very well aligned with original ideas about OOP.
I would do it differently though.
I would build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.
(I)View has a (i)Cad is the correct model of the
interface IView
interface ScreenView : IView
interface CadView : IView
But I know too little about CAD to be sure.
Arne

Thanks again Arne, I'll research domain model and try to figure out what
you're saying :-) learning a ton here



---
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 build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.

<>

Post by mp
Thanks again Arne, I'll research domain model and try to figure out what
you're saying :-) learning a ton here

so my first search on domain model turns up the DSL tool in vis studio
and the concept of Domain driven design
is that the direction i should be looking into?


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

[Registered User]

Post by mp
<>

Post by mp

Post by Arne Vajhøj
I would build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.

<>

Post by mp
Thanks again Arne, I'll research domain model and try to figure out what
you're saying :-) learning a ton here

so my first search on domain model turns up the DSL tool in vis studio
and the concept of Domain driven design
is that the direction i should be looking into?

I see several layers; the interfaces, the model, the view model and the view.
There's an interface that models must implement to support the view model.Once
again the view model uses an implementation of model's interface to implement
the view model to support the view.

There'a much indirection and separation of concerns. The view doesn't care about
the view model or anything behind it because the view uses an interface's
implementation. There can be as many implementations of the view model interface
as needed. The same goes for the relationship between the model and view models
layers.

There can be abstract classes between interfaces and concrete implementation.
Much depends upon the common functionality the derived classe can use.

That was probably clear as mud. Read it enough at some point it will start
making sense. At some point all of a sudden you'll get it! I don't think it will
take too long.

Use your favorite search engine with the argument 'S.O.L.I.D'. Once you start to
understand SOLID programming you can come up with mutiple answers to the one
problem you're trying to solve. You don't want the first answer, you want the
most suitable answer.

You're 20% there with SOLID programming, Both the single responsibility theory
and the separation of concerns can represent the S.

[mp]

Post by Registered User

Post by mp
<>

Post by mp

Post by Arne Vajhøj
I would build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.

<>

Post by mp
Thanks again Arne, I'll research domain model and try to figure out what
you're saying :-) learning a ton here

so my first search on domain model turns up the DSL tool in vis studio
and the concept of Domain driven design
is that the direction i should be looking into?

I see several layers; the interfaces, the model, the view model and the view.
There's an interface that models must implement to support the view model.Once
again the view model uses an implementation of model's interface to implement
the view model to support the view.
There'a much indirection and separation of concerns. The view doesn't care about
the view model or anything behind it because the view uses an interface's
implementation. There can be as many implementations of the view model interface
as needed. The same goes for the relationship between the model and view models
layers.
There can be abstract classes between interfaces and concrete implementation.
Much depends upon the common functionality the derived classe can use.
That was probably clear as mud. Read it enough at some point it will start
making sense. At some point all of a sudden you'll get it! I don't think it will
take too long.
Use your favorite search engine with the argument 'S.O.L.I.D'. Once you start to
understand SOLID programming you can come up with mutiple answers to the one
problem you're trying to solve. You don't want the first answer, you want the
most suitable answer.
You're 20% there with SOLID programming, Both the single responsibility theory
and the separation of concerns can represent the S.

LOL :-) holy cow! I love that, read it till you get it! that's
definitely what i have to do...re read things a few hundred times and
eventually my brain 'might' start absorbing some of it :-)
Thanks so much for all your help

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

[Arne Vajhøj]

Post by Registered User

Post by mp
<>

Post by mp

Post by Arne Vajhøj
I would build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.

<>

Post by mp
Thanks again Arne, I'll research domain model and try to figure out what
you're saying :-) learning a ton here

so my first search on domain model turns up the DSL tool in vis studio
and the concept of Domain driven design
is that the direction i should be looking into?

I see several layers; the interfaces, the model, the view model and the view.
There's an interface that models must implement to support the view model.Once
again the view model uses an implementation of model's interface to implement
the view model to support the view.
There'a much indirection and separation of concerns. The view doesn't care about
the view model or anything behind it because the view uses an interface's
implementation. There can be as many implementations of the view model interface
as needed. The same goes for the relationship between the model and view models
layers.

MVVM is one approach. It is not the only approach.

Arne

[Registered User]

Post by Arne Vajhøj
MVVM is one approach. It is not the only approach.

My intent wasn't to tout the MVVM pattern. Rather it was used as an example to
illustrate the flexibility interfaces and their implementations can provide. The
OP is trying to design a hierarchy which can likely use both inheritance and
composition.

[Arne Vajhøj]

Post by mp
<>

Post by mp

Post by Arne Vajhøj
I would build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.

<>

Post by mp
Thanks again Arne, I'll research domain model and try to figure out what
you're saying :-) learning a ton here

so my first search on domain model turns up the DSL tool in vis studio
and the concept of Domain driven design
is that the direction i should be looking into?

Start with traditional domain model.

Wait with DDD.

And DSL is not something entirely different.

Arne

[mp]

Post by Arne Vajhøj

Post by mp
<>

Post by mp

Post by Arne Vajhøj
I would build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.

<>

Post by mp
Thanks again Arne, I'll research domain model and try to figure out what
you're saying :-) learning a ton here

so my first search on domain model turns up the DSL tool in vis studio
and the concept of Domain driven design
is that the direction i should be looking into?

Start with traditional domain model.
Wait with DDD.
And DSL is not something entirely different.
Arne

Thanks Arne, I'm guessing you meant "DSL *is* different" ???

---
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 mp

Post by Arne Vajhøj
I would build a domain model without any references to
any view technology and the a separate view module
knowing about the domain model.

<>

Post by mp
Thanks again Arne, I'll research domain model and try to figure out what
you're saying :-) learning a ton here

so my first search on domain model turns up the DSL tool in vis studio
and the concept of Domain driven design
is that the direction i should be looking into?

Start with traditional domain model.
Wait with DDD.
And DSL is not something entirely different.

Thanks Arne, I'm guessing you meant "DSL *is* different" ???

Yes.

Wrote something and edited badly and ended up saying the
oppsosite.

:-(

Arne