About Single Responsibility Principle

[JiiPee]

(sorry this is only 50% C++ issue but did not find any active group so
posted here)

Just a simple question regarding what am working with now. Its using
OpenGL with MFC (window programming, using views... view is one type of
window, dialog could be another type of window etc).

In View's (which is a window) draw function I could do:
1)
void MyView::OnDraw(CDC* pView)
{
    // do all opengl drawing calls here - could be 10-20 lines of code
}

or another approach (also recomended by some):
2)
void MyView::OnDraw(CDC* pView)
{
    m_openGLRenderer.Render(pView); // or just openGLRenderer.Render();
as the renderer knows the window already
}

So would have a member variable COpenGLRenderer m_openGLRenderer; and
just let this object do the opengl stuff. So view basically having no
(or only few) opengl related things in it.
Which way is better? If I do 1) the opengl code is bound with View-type
of Window (so could not re-use with other type of windowses for example,
like dialog window etc).

Does 1) break the "Single Responsibility Principle" rule because then
MyView is doing View-specific things and also OpenGL specific things? Or
can we think that view and opengl are both drawing issues so still
single responsibility?
So should the View just call opengl as much as possible via a
openGLrenderer object and keep View implementation as small as possible
and independent of the opengl? Or could just put all opengl
functionality inside view class?

[Paavo Helde]

On 7.11.2018 19:48, JiiPee wrote:
> (sorry this is only 50% C++ issue but did not find any active group so
> posted here)
>
> Just a simple question regarding what am working with now. Its using
> OpenGL with MFC (window programming, using views... view is one type of
> window, dialog could be another type of window etc).
>
> In View's (which is a window) draw function I could do:
> 1)
> void MyView::OnDraw(CDC* pView)
> {
> // do all opengl drawing calls here - could be 10-20 lines of code
> }
>
> or another approach (also recomended by some):
> 2)
> void MyView::OnDraw(CDC* pView)
> {
> m_openGLRenderer.Render(pView); // or just openGLRenderer.Render();
> as the renderer knows the window already
> }

In my experience, whenever you just have a vague feeling that asking
such a question might be justified, it means that the components should
be definitely separated.

> So would have a member variable COpenGLRenderer m_openGLRenderer; and
> just let this object do the opengl stuff. So view basically having no
> (or only few) opengl related things in it.

Seems fine, except that the name COpenGLRenderer is using the MS/MFC
name conventions. If this is a class written by yourself it should not
use the "C" prefix, to reduce confusion.

> Which way is better? If I do 1) the opengl code is bound with View-type
> of Window (so could not re-use with other type of windowses for example,
> like dialog window etc).
>
> Does 1) break the "Single Responsibility Principle" rule because then
> MyView is doing View-specific things and also OpenGL specific things? Or

Exactly.

> can we think that view and opengl are both drawing issues so still
> single responsibility?

Nope. MFC and openGL are two very different things.

[JiiPee]

Thanks very much, because I needed some experts comments. I actually
agree with you but I have to get others convinced :).
(my comments below)

On 07/11/2018 19:10, Paavo Helde wrote:
>
> In my experience, whenever you just have a vague feeling that asking
> such a question might be justified, it means that the components
> should be definitely separated.

I also feel this...

>
>> So would have a member variable COpenGLRenderer m_openGLRenderer; and
>> just let this object do the opengl stuff. So view basically having no
>> (or only few) opengl related things in it.
>
> Seems fine, except that the name COpenGLRenderer is using the MS/MFC
> name conventions. If this is a class written by yourself it should not
> use the "C" prefix, to reduce confusion.

sure, I also dont use C elsewhere.

>
>> Which way is better? If I do 1) the opengl code is bound with View-type
>> of Window (so could not re-use with other type of windowses for example,
>> like dialog window etc).
>>
>> Does 1) break the "Single Responsibility Principle" rule because then
>> MyView is doing View-specific things and also OpenGL specific things? Or
>
> Exactly.

I also thought so

>
>> can we think that view and opengl are both drawing issues so still
>> single responsibility?
>
> Nope. MFC and openGL are two very different things.

yeps! somebody agrees me , Bingo, hehe

>
>

[Richard]

[Please do not mail me a copy of your followup]

n...@notvalid.com spake the secret code
<SzFED.148182$Do.1...@fx31.am4> thusly:

>Does 1) break the "Single Responsibility Principle" rule because then
>MyView is doing View-specific things and also OpenGL specific things?

Yes.

>Or
>can we think that view and opengl are both drawing issues so still
>single responsibility?

Nope.

>So should the View just call opengl as much as possible via a
>openGLrenderer object and keep View implementation as small as possible
>and independent of the opengl?

Yes.

>Or could just put all opengl
>functionality inside view class?

Nope.

In addition to what you observed about violating SRP, combining these
two together makes it difficult to unit test these classes.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[JiiPee]

On 07/11/2018 20:01, Richard wrote:
> In addition to what you observed about violating SRP, combining these
> two together makes it difficult to unit test these classes.

Thanks, good to hear second confirmation :).

Yes I sense there are many benefits lurking there... intuitively also.

[Manfred]

On 11/7/2018 6:48 PM, JiiPee wrote:
> Or can we think that view and opengl are both drawing issues so still
> single responsibility?

As others have already answered, MFC and OpenGL are very different things.
More generally, the View class takes care of interfacing with the
display context, i.e. the windowing system.
The Renderer class takes care of... well, the rendering.
These are different things, also considering different alternatives -
e.g. X-Windows and DirectX. (the latter only works on Windows, but you
get the point)

Ideally the only overlap between the two should be mapping the HGLRC
onto the HDC.

[JiiPee]

thanks, I agree

[Pavel]

JiiPee wrote:
> (sorry this is only 50% C++ issue but did not find any active group so posted here)
>
> Just a simple question regarding what am working with now. Its using OpenGL with
> MFC (window programming, using views... view is one type of window, dialog could
> be another type of window etc).
>
> In View's (which is a window) draw function I could do:
> 1)
> void MyView::OnDraw(CDC* pView)
> {
>     // do all opengl drawing calls here - could be 10-20 lines of code

usually, it's more... or will grow to more soon.

> }
>
> or another approach (also recomended by some):
> 2)
> void MyView::OnDraw(CDC* pView)
> {
>     m_openGLRenderer.Render(pView); // or just openGLRenderer.Render(); as the
> renderer knows the window already

This might not be good. It might be appropriate to extract HDC and the
parameters that might be useful to the drawer here (e.g. go through all
GDC::Get.. functions to see what might be useful for the renderer).

Then, there are data to render. Some may be stored in MyView (some of which may
be windows system -specific) and some elsewhere; in any case, I would try to
extract the data as relatively low-level structures (often as simple as
[array(s) of] int(s)/double(s)/string(s)) in OnDraw and pass these to the
renderer to make it actually independent of the view -- unless it's
prohibitively expensive.

> }
>
> So would have a member variable COpenGLRenderer m_openGLRenderer; and just let
> this object do the opengl stuff. So view basically having no (or only few)
> opengl related things in it.
> Which way is better? If I do 1) the opengl code is bound with View-type of
> Window (so could not re-use with other type of windowses for example, like
> dialog window etc).
>
> Does 1) break the "Single Responsibility Principle" rule because then MyView is
> doing View-specific things and also OpenGL specific things?

Roughly, yes. But try to decompose your problem on the basis of the actual
component roles that they play in your program rather than the tools/libraries
they use.

I usually use iterative process. First, draft responsibilities and identify some
components. Then try to model data flows between the components. If these look
unnatural or are inefficient, I might need to re-think what components are. If
data structures and data feeds look efficient and the data structures/classes
are sufficiently independent of the component classes ("doers"), I take it as an
indication of a good decomposition.

> Or can we think that
> view and opengl are both drawing issues so still single responsibility?
> So should the View just call opengl as much as possible via a openGLrenderer
> object and keep View implementation as small as possible and independent of the
> opengl?

Too little is known about the problem to say if one object is even enough. If
you do something very small and view-specific, noone will probably reuse the
renderer (except for the unit test, maybe) so you may do it in this function
(although, with opengl it is rarely small in terms of loc count). If, on the
other hand, the renderer renders multiple potentially useful but slightly custom
objects (e.g. 9 instances of 3 versions of your company logo flying around the
view), it might make sense to factor these composers out of the renderer. Or, a
view can directly own more than one "renderer". Long story short, it depends on
the specifics.

Or could just put all opengl functionality inside view class?

You could, but it is probably not a good idea. But sometimes I would just start
writing OnDraw and refactor as I go when it is more clear what should go where
(this process is also known as hacking -- in a good way :-) ).

HTH
-Pavel

[JiiPee]

On 08/11/2018 06:46, Pavel wrote:
> If
> you do something very small and view-specific, noone will probably reuse the
> renderer (except for the unit test, maybe) so you may do it in this function
> (although, with opengl it is rarely small in terms of loc count).

But if you do it in Renderer, then if later on you need to draw in
another type of window, lets say in Dialog-window, then you can re-use
this renderer , isnt it? its not necessary the plan currnetly to use it
in a dialog, but it would give that opportunity... as there is some
chance its needed in other type of windows as well. or not?


CView is only one type of window, there are like 20 other windows where
you could also draw opengl... at least in theory

[Öö Tiib]

I'm uncertain what you want to say with that.
Do you want instances of different CViews (say MyView,
MapView and InventoryView) to be drawn same way?
Feels unimaginable even when these all are showing
same, fat data "document" instance of MFC, because
usually different views are required to show different
aspects of data. With windows of clearly different
purpose (like dialog or view) it is even harder to
imagine.

Therefore it makes more sense to have different,
view-specific renderers (like MyRenderer, MapRenderer
and InventoryRenderer) rather than some single, universal
"OpenGLRenderer" that you seem to imply.

[JiiPee]

On 08/11/2018 14:18, Öö Tiib wrote:
> On Thursday, 8 November 2018 11:44:34 UTC+2, JiiPee wrote:
>> On 08/11/2018 06:46, Pavel wrote:
>>> If
>>> you do something very small and view-specific, noone will probably reuse the
>>> renderer (except for the unit test, maybe) so you may do it in this function
>>> (although, with opengl it is rarely small in terms of loc count).
>>
>> But if you do it in Renderer, then if later on you need to draw in
>> another type of window, lets say in Dialog-window, then you can re-use
>> this renderer , isnt it? its not necessary the plan currnetly to use it
>> in a dialog, but it would give that opportunity... as there is some
>> chance its needed in other type of windows as well. or not?
>>
>> CView is only one type of window, there are like 20 other windows where
>> you could also draw opengl... at least in theory
> I'm uncertain what you want to say with that.
> Do you want instances of different CViews (say MyView,
> MapView and InventoryView) to be drawn same way?

No, I was talking about different type of views in MFC. In MFC you can
have CDialog,  CView, CSCrollView. They are all inherited from genaral
window CWnd. So if i put all opengl code into  CView then I cannot
re-use this in CDialog.

class CView  : public CWnd {}

class CDialog : public CWnd {}

> Feels unimaginable even when these all are showing
> same, fat data "document" instance of MFC, because
> usually different views are required to show different
> aspects of data. With windows of clearly different
> purpose (like dialog or view) it is even harder to
> imagine.
>
> Therefore it makes more sense to have different,
> view-specific renderers (like MyRenderer, MapRenderer
> and InventoryRenderer) rather than some single, universal
> "OpenGLRenderer" that you seem to imply.

But OpenGLRenderer could handle general opengl drawing things general
for all windows? Then obviously the real drawing is done in a class
derived from OpenGLRenderer :

class DrawingCars : OpenGLRenderer {}

[JiiPee]

On 08/11/2018 14:25, JiiPee wrote:
> No, I was talking about different type of views in MFC.

sorry i meant "I was talking about different type of *windows * in MFC"

[JiiPee]

On 08/11/2018 14:18, Öö Tiib wrote:

> Therefore it makes more sense to have different,
> view-specific renderers (like MyRenderer, MapRenderer
> and InventoryRenderer) rather than some single, universal
> "OpenGLRenderer" that you seem to imply.

But a good idea would be to have parent class OpenGLRenderer and put all
general opengl  stuff there and then inherit

MapRenderer

from it to do the map drawing?

[Öö Tiib]

My point was that MapView's void OnDraw(CDC* pdc)
override; can want to call a MapRenderer but it feels
unlikely that it wants to call InventoryRenderer.
Therefore existence of OpenGLRenderer does not
concern it any.

So all depends how that OpenGLRenderer base class
helps MapRenderer. What it precisely does and is it
useful for InventoryRenderer too?

[JiiPee]

On 08/11/2018 17:05, Öö Tiib wrote:
> So all depends how that OpenGLRenderer base class
> helps MapRenderer.

it can for example do the opengl initiliazation which is always the same
process for all views (with passing of the drawing device context/window
handle).

[Pavel]

This is probably correct more often than not, but still not always.

An example where it might not be that straighforward: if whatever you want to
draw using openGL requires data from your CDocument, you won't have that in
CDialog. Obviously, a particular kind of document may be displayed in more than
one kind of view -- but even then some parameters of the view can alter how the
information from the document is displayed. You can certainly try to extract
these parameters from a view and feed your renderer with these parameters and
information from that document -- but this logic, in combination with drawing
code, will most certainly take more than 20 lines of code.

Or, if what you are creating is some small custom reusable cool visual component
(say, a custom button, whose document is, for example, some very special
combination of text some graphics and animation, specific to that component,
possibly dynamic i.e. changing with time), it is highly unlikely that you need
another view with exactly same drawing + interaction logic -- and view is good
for wiring in all the data and user-interaction events (if any); then you might
appreciate packing this all in a single class. Your desired rendering may need
to rely on more view-specific data (I do not mean document, but, say, even CWnd
and parent CWnd parameters and events) than you initially planned and you might
find yourself busy programming wiring from those to your openGL renderer instead
of working on actual drawing.

On the other hand, if you want to provide two ways of rendering: one basic with
GDI and another, advanced, with OpenGL, you will have to decompose your data
flows anyway. But even then it might turn out easier to just create two parallel
views, basic and advanced -- because a view essentially is not much more than
wiring connecting rendering to document data, events and window system state.
Also, event handling might want some information back from the renderer for
usability -- think of clicking on animated object.

Where you might really appreciate a separate renderer and data flow
decomposition is in porting your app or component away from MFC to another
platform allowing OpenGL. Just remember that work on portable/multi-platform
components and that decomposition will take your valuable time, so I would not
do it just because it is "the right thing".

Long story short -- optimal design depends on what you are doing, what data the
renderer will eventually need and the feedback the view might need from the
renderer.

>

[JiiPee]

On 09/11/2018 05:11, Pavel wrote:
> An example where it might not be that straighforward: if whatever you want to
> draw using openGL requires data from your CDocument, you won't have that in
> CDialog.

1) Does the opengl data need to be defined in CDocument? Can we do this:


class MyOpenGLData

{

// data for opengl

}

class CMyDocument : CDocument

{

MyOpenGLData m_openglData;

}

And thus CMyDocument would only have non-opengl data.

This way Renderer and OpenglDAta are both isolated from the MFC
view/documen/frame system


2) How about doing this only for those windows/views which uses
CDocument, like ScrollView, FormView. So then would be easy to re-use it
in those views, and if needs to use it in CDialog then could do it in a
different way there.

I am not sure if CDocument can be used with CDialog/CWnd. So it cannot
be used with them?

[JiiPee]

On 09/11/2018 05:11, Pavel wrote:
>

> Or, if what you are creating is some small custom reusable cool visual component
> (say, a custom button, whose document is, for example, some very special
> combination of text some graphics and animation, specific to that component,
> possibly dynamic i.e. changing with time), it is highly unlikely that you need
> another view with exactly same drawing + interaction logic -- and view is good
> for wiring in all the data and user-interaction events (if any); then you might
> appreciate packing this all in a single class. Your desired rendering may need
> to rely on more view-specific data (I do not mean document, but, say, even CWnd
> and parent CWnd parameters and events) than you initially planned and you might
> find yourself busy programming wiring from those to your openGL renderer instead
> of working on actual drawing.

You mean that all future Views/Windows would have totally different
drawing needs, thus renderer would not be a good way to handle them all
as the windows have totally different drawing needs?
In my project this is not really the case as all windows will be drawing
simple graphics like shapes, boxes, x,y,z axis, wireframes etc. Things
normally drawn in 3D modelling.

> On the other hand, if you want to provide two ways of rendering: one basic with
> GDI and another, advanced, with OpenGL,

No, this is not a plan. Only opengl. Also that seems alot of work to
separate them. Only if needed in the future then would do that. But not
if there is no immediate need.

> Where you might really appreciate a separate renderer and data flow
> decomposition is in porting your app or component away from MFC to another
> platform allowing OpenGL. Just remember that work on portable/multi-platform
> components and that decomposition will take your valuable time, so I would not
> do it just because it is "the right thing".

I am not planning it to be portable like this.

> Long story short -- optimal design depends on what you are doing, what data the
> renderer will eventually need and the feedback the view might need from the
> renderer.

The drawing will be simple OpenGL drawing modelling 3D objects (like
tools, table, etc... like the 3D modelling programs.). rotating them,
zooming etc... all basic functionalities.

[Pavel]

JiiPee wrote:
> On 09/11/2018 05:11, Pavel wrote:
>> An example where it might not be that straighforward: if whatever you
>> want to
>> draw using openGL requires data from your CDocument, you won't have
>> that in
>> CDialog.
>
>
> 1) Does the opengl data

I am not sure what you mean by "openGL data". I referred to the data
that openGL drawing may require -- but these would probably be your
domain-specific data with lots of stuff relevent and irrelevant to
drawing (of course it could be openGL models exclusively, too).

need to be defined in CDocument?

Of course not but it's convenient as wiring is there.

Can we do this:
>
>
> class MyOpenGLData
>
> {
>
> // data for opengl
>
> }
>
> class CMyDocument : CDocument
>
> {
>
> MyOpenGLData m_openglData;
>
> }
>
> And thus CMyDocument would only have non-opengl data.
>
> This way Renderer and OpenglDAta are both isolated from the MFC
> view/documen/frame system

You can compose your document from other objects. Or you could rename
CMyDocument to CMyOpenGLData and lose the extra object. Whichever is
better depends on how else you plan to use MyOpenGLData.

>
>
> 2) How about doing this only for those windows/views which uses
> CDocument, like ScrollView, FormView. So then would be easy to re-use it
> in those views, and if needs to use it in CDialog then could do it in a
> different way there.
>
> I am not sure if CDocument can be used with CDialog/CWnd. So it cannot
> be used with them?

You can and most probably will add your custom CView to some kind of
top-level or higher-level CWnd as a child anyway.
>

[Pavel]

No. I meant that you create some CMyShapeDrawingView with lots of useful
customizable properties and add it to whatever parent CWnd you want and
use MFC event wiring to handle interesting events coming from parent
windows and access their properties.

> In my project this is not really the case as all windows will be drawing
> simple graphics like shapes, boxes, x,y,z axis, wireframes etc. Things
> normally drawn in 3D modelling>

>> On the other hand, if you want to provide two ways of rendering: one
>> basic with
>> GDI and another, advanced, with OpenGL,
>
> No, this is not a plan. Only opengl. Also that seems alot of work to
> separate them. Only if needed in the future then would do that. But not
> if there is no immediate need.
>
>> Where you might really appreciate a separate renderer and data flow
>> decomposition is in porting your app or component away from MFC to
>> another
>> platform allowing OpenGL. Just remember that work on
>> portable/multi-platform
>> components and that decomposition will take your valuable time, so I
>> would not
>> do it just because it is "the right thing".
>
> I am not planning it to be portable like this.
>
>> Long story short -- optimal design depends on what you are doing, what
>> data the
>> renderer will eventually need and the feedback the view might need
>> from the
>> renderer.
>
> The drawing will be simple OpenGL drawing modelling 3D objects (like
> tools, table, etc... like the 3D modelling programs.). rotating them,
> zooming etc... all basic functionalities.

Well, it sounds like you need to handle lots of user input events that
are bound to specific locations at your rendered object to select them.
You need to decide how you are going to map your gestures to locations
at your 3D objects. There is more than one way. I have never done it
myself. You might need to research it. See e.g.
http://www.opengl-tutorial.org/miscellaneous/clicking-on-objects/ or ask
in some OpenGL group.

On the other hand, if you meant to only display a single object at a
time, you can do a "non -OO UI", controlling your object with bunch of
buttons, scrollers etc. outside of your view and/or a set of keyboard
accelerators. In any case you will need to update your scene on these
actions. This may be done, e.g. by changing your CDocument and notifying
your view but you are of course free to use an entirely custom domain
data structures. Frankly, the more I think about it, the more I like the
idea of using CDocument/CView framework for this kind of job. It was put
together for a reason and is largely based on a sound theory developed
by really smart people before Microsoft came to be.
>
>

[JiiPee]

On 10/11/2018 03:48, Pavel wrote:
> Frankly, the more I think about it, the more I like the
> idea of using CDocument/CView framework for this kind of job. It was put
> together for a reason and is largely based on a sound theory developed
> by really smart people before Microsoft came to be.

yes am planning to use that framework. But am still struggling to
understand you point why isolating opengl code from View and possibly
document code from CDocument would be bad.


I can read you messages.. but is it possible to make a very simple,
couple of lines example code illustrating this issue (why Renderer would
be bad/worse)?

[Pavel]

I have never said it would be bad. All I am saying you might have to
code that renderer class, logic to pass data to it and maybe to get some
coordinates back out of it (to use in view event handlers) without a
clear reward for writing it -- especially now that you say you are going
to use CDocument/CView framework -- which means you won't be able to
reuse that renderer with CDialog directly (i.e. without a CView as an
intermediary). I don't think I can put it simpler than this.

I apologize, but I will not write any code just to say something like
"the issue with this code is that it is unnecessary". If you share your
code with the renderer or part of it, I promise to point out the lines
that would be unnecessary in my opinion in case you wrote your drawing
code directly in OnDraw (although I am sure you can see it for yourself).

To start with, this line of code of those few lines you shared in your
original post:

m_openGLRenderer.Render(pView); // or just openGLRenderer.Render();
as the renderer knows the window already

can be ditched together with the renderer class declaration. This may
not seem like much but a) you did not give me much to "work with"; and
b) in the real program this line will be more complex as you need to
pass in the data you want to draw and maybe get something back (am I
repeating myself? not again.. :-)).

[JiiPee]

On 11/11/2018 02:07, Pavel wrote:
> To start with, this line of code of those few lines you shared in your
> original post:
>
> m_openGLRenderer.Render(pView); // or just openGLRenderer.Render();
> as the renderer knows the window already
>
> can be ditched together with the renderer class declaration.

"ditched": Do you mean that the OnDraw in view could be totally empty,
and the Renderer gets the Windows draw message itself? This could be
done in Views message map by saying there that the the draw message
handler function is in Render class? Is this what you mean?

[JiiPee]

On 11/11/2018 02:07, Pavel wrote:

> you might have to
> code that renderer class, logic to pass data to it and maybe to get some
> coordinates back out of it (to use in view event handlers) without a
> clear reward for writing it

Do you mean that the Renderer is dependent on the View class? Renderer
needs a pointer to view-object?

"get some coordinates back out of it (to use in view event handlers)"

Dont fully understand.. because for example using getters and setters is
not dependent on the View. If we have getters and setters in Renderer
Dialog could also use them. But obviously you mean something else...

Or you are talking about some kind of feedback function which needs to
pass data live to View as its doing calculations?

[Pavel]

No, I mean it is unnecessary (can be removed from the design).

[Pavel]

JiiPee wrote:
> On 11/11/2018 02:07, Pavel wrote:
>> you might have to
>> code that renderer class, logic to pass data to it and maybe to get some
>> coordinates back out of it (to use in view event handlers) without a
>> clear reward for writing it
>
>
> Do you mean that the Renderer is dependent on the View class? Renderer needs a
> pointer to view-object?

No, all I am saying, I do not see a clear benefit from creating Renderer -- but
it is obvious it comes with at least some costs -- which begs the question "do
we really need it?"

>
>
> "get some coordinates back out of it (to use in view event handlers)"
>
> Dont fully understand.. because for example using getters and setters is not
> dependent on the View. If we have getters and setters in Renderer Dialog could
> also use them. But obviously you mean something else...

Take a look at the Web references I posted before in this thread. If you want to
make your UI "object-oriented", e.g. you want to be able to click at a corner of
your OpenGL-rendered object and drag to rotate it, you would need some way to
translate the 2-D discrete coordinates of your click (which is what you will get
as a CPoint in some CWnd or CView callback) to the coordinates of your object in
OpenGL 3-D coordinate system -- for which there are multiple ways, some of which
are described at those references. And in general you will need some coordinates
or other numbers (translation parameters?, the results of ray rendering at your
CView plane?) that can be computed along with OpenGL rendering for such translation.

Of course, if you are ok with a simpler UI (e.g. "rotate left/right/up/down"
buttons outside of the view that renders your objects), this is not needed, so I
am saying "maybe". But a simple UI may be difficult to use if you want to render
more than one object in the view, because you would need to invent some way,
other than point-and-click, to select the object for rotation.

>
> Or you are talking about some kind of feedback function which needs to pass data
> live to View as its doing calculations?

Yes, it could be a callback (probably with some accompanying data, so maybe an
object and a member) or simply some data structure (probably a member of your
custom CView) that your 3-D drawing code will keep up-to-date and your mouse
event callback would use. For the relatively simple task you described, the
callback seems a little over-engineering to me (again) although it could be a
good idea for some more complex problem.