How to design C++ OOP better?

[Immortal Nephi]

I have an idea how to design an object in a better way. I would like
to give you
my thought example. Please let me know what you think if it is best
object design.
Please recommend me any book which it teaches me how to design C++ OOP
better as long
as I know how to program OOP in C++.
Think of ancient 6502 microprocessor which it was used for Commodore,
Atari, and
Apple II. This MPU_6502 is an object of MPU_6502 class. All member
variables are
hidden like internal registers of A, X, and Y. Only address bus and
data bus
member variables are available using Set() and Get() functions.
This MPU_6502 object can be reused to the client users. What happen
if
programmers want to create another object which it is called
MPU_6502_Debug. This
MPU_6502 object guards against MPU_6502_Debug from accessing internal
registers
using Set() and Get() functions. MPU_6502_Debug object needs to find
a way how to
obtain internal registers from MPU_6502 object.
The friend keyword may be the option so friend class MPU_6502_Debug
can be added
into MPU_6502 class and you create a pointer in MPU_6502_Debug object
to access
MPU_6502 object's internal registers.
If you think that friend keyword is a bad OOP design, please offer me
another
good example how MPU_6502 object and MPU_6502_Debug object can be done
to process
internal registers inside main() function.
Please advise. I appreciate your help. Take a look at my C++ OOP
code below. They are too short codes as examples.

class MPU_6502
{
public:
MPU_6502() {}
~MPU_6502() {}
void Run() { /* Process Address Bus and Data Bus to modify internal
A, X, and Y registers */ }

unsigned int Get_Address_Bus() { return Address_Bus; }
unsigned int Get_Data_Bus() { return Data_Bus; }
void Set_Data_Bus(unsigned int data_bus) { Data_Bus = data_bus; }

// You are not allowed to use Set() & Get() functions below as a true
black box.

// void Set_A(unsigned int a) { A = a; }
// void Set_X(unsigned int x) { X = x; }
// void Set_Y(unsigned int y) { Y = y; }

// unsigned int Get_A() const { return A; }
// unsigned int Get_X() const { return X; }
// unsigned int Get_Y() const { return Y; }

private:
unsigned int A;
unsigned int X;
unsigned int Y;

unsigned int Address_Bus;
unsigned int Data_Bus;
};

class MPU_6502_Debug
{
public:
MPU_6502_Debug() {}
~MPU_6502_Debug() {}
void Run()
{ /* Need to get internal registers from MPU_6502 object to process
debugging */ }

void Set_A(unsigned int a) { A = a; }
void Set_X(unsigned int x) { X = x; }
void Set_Y(unsigned int y) { Y = y; }

private:
unsigned int A;
unsigned int X;
unsigned int Y;
};

int main(void)
{
unsigned char* RAM = new unsigned char [0x10000];

MPU_6502 mpu;

mpu.Run(); // Run many times every time address bus comes.
mpu.Set_Data_Bus( RAM[ mpu.Get_Address_Bus() ] ); // Get Data bus
from RAM's address bus
mpu.Run(); // Continues running as long as it can.

/* This MPU_6502 object is a black box like a chip. This chip has
only address bus and
data bus. You send message to MPU_6502 object to retreive address
bus and data
bus. It does not allow you to access internal registers, but only
Run() can do process
internal registers. No Get internal registers functions and set
internal registers
functions are allowed to be used to the client. This MPU_6502 object
is a good
object design for best data protection. */

MPU_6502_Debug mpu_debug; // You can define MPU_6502_Debug object
anytime you want.

for (int loop = 0; loop < 10; loop++) // can be endless loop as you
want.
{
mpu.Run();
mpu_debug.Set_A( 0x40 ); // How can you do it?
mpu_debug.Set_X( 0xC1 ); // How can you do it?
mpu_debug.Set_Y( 0x80 ); // How can you do it?
mpu_debug.Run();
}

delete [] RAM;

return 0;
}

Nephi

[Ian Collins]

Immortal Nephi wrote:

I have an idea how to design an object in a better way. I would like
to give you
my thought example. Please let me know what you think if it is best
object design.

Can you fix your like wrap and post again? This is very had to follow.

--
Ian Collins.

[Sam]

Immortal Nephi writes:

[ somewhat complicated design and situation ]

This MPU_6502 object can be reused to the client users. What happen
if
programmers want to create another object which it is called
MPU_6502_Debug. This
MPU_6502 object guards against MPU_6502_Debug from accessing internal
registers
using Set() and Get() functions. MPU_6502_Debug object needs to find
a way how to
obtain internal registers from MPU_6502 object.

[ … ]

I think I understand what you're trying to do. There are a number of ways of
approaching this design that's probably cleaner, and avoids having to
declare a friend class.

Consider placing all the registers as protected members of MPU_6502_Debug:

class MPU_6502_debug {

protected:
unsigned int A;
unsigned int X;
unsigned int Y;

unsigned int Address_Bus;
unsigned int Data_Bus;

public:

// Your various get and set methods go here.
};

Then, privately subclass MPU_6502_Debug,

class MPU_6502 : private MPU_6502_Debug {

public:
// Your MPU_6502 functions

MPU_6502_Debug &getDebug() { return *this; }

const MPU_6502_Debug &getDebug() const { return *this; }
};

The MPU_6502 subclass has direct access to the registers, from its
superclass, which is private and cannot be directly accessed. Use the
getDebug() method to retrieve the reference to the superclass, which gives
you full access. The nice thing about this approach is that in contexts
where your MPU_6502 object is constant, you'll only have access to the
constant debug superclass object reference, and, consequently, only the
constant get() methods in the superclass.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAki4vW0ACgkQx9p3GYHlUOIiJgCggCGJ3v+MQR FLH90L9xQn0ii9
VEcAn2Xaq7D39Wv3DLjOafq+LvKbKxFp
=CRmg
-----END PGP SIGNATURE-----

[Immortal Nephi]

On Aug 29, 10:24*pm, Sam <[e-mail]:

*application_pgp-signature_part
< 1KViewDownload

Immortal Nephi writes:

[ somewhat complicated design and situation ]
* *This MPU_6502 object can be reused to the client users. *What happen
if
programmers want to create another object which it is called
MPU_6502_Debug. *This
MPU_6502 object guards against MPU_6502_Debug from accessing internal
registers
using Set() and Get() functions. *MPU_6502_Debug object needs to find
a way how to
obtain internal registers from MPU_6502 object.
[ … ]

I think I understand what you're trying to do. There are a number of waysof
approaching this design that's probably cleaner, and avoids having to
declare a friend class.

Consider placing all the registers as protected members of MPU_6502_Debug:

class MPU_6502_debug {

protected:
* * unsigned int A;
* * unsigned int X;
* * unsigned int Y;

* * unsigned int Address_Bus;
* * unsigned int Data_Bus;

public:

* * // Your various get and set methods go here.

};

Then, privately subclass MPU_6502_Debug,

class MPU_6502 : private MPU_6502_Debug {

public:
* * * // Your MPU_6502 functions

* * * MPU_6502_Debug &getDebug() { return *this; }

* * * const MPU_6502_Debug &getDebug() const { return *this; }

};

The MPU_6502 subclass has direct access to the registers, from its
superclass, which is private and cannot be directly accessed. Use the
getDebug() method to retrieve the reference to the superclass, which gives
you full access. The nice thing about this approach is that in contexts
where your MPU_6502 object is constant, you'll only have access to the
constant debug superclass object reference, and, consequently, only the
constant get() methods in the superclass.

Thanks for provding me subclass example. Can you please add main()
function example? This main() function helps you to define MPU_6502
object and MPU_6502_Debug object. What do this look like? The client
user can decide if they want to define only MPU_6502 object in this
main() function. Sometimes, they want to define both MU_6502 object
and MPU_6502_Debug object if they need MPU_6502_Deug object.

I take more time to learn how to write C++ OOP in a better design way.

Thanks again.

Nephi

[Jerry Coffin]

In article <1872f022-3fc0-4ff6-bc94-
92**********@d1g2000hsg.googlegroups.com>, Im************@satx.rr.com
says...

I have an idea how to design an object in a better way.

The first part of good design (OO or otherwise) is applying knowledge of
the domain, first acquiring that knowledge if necessary.

In this case, it looks to me like you're trying to create a design that
just doesn't work much like a real 6502 microprocessor did. For example,
you mention making the address bus available to external code via get
and set methods. On the 6502, the address bus was output-only, so an
emulator that took inputs on the address bus wouldn't be very accurate
at all.

An accurate emulation of a microprocessor starts with its data sheet.
Generally speaking, you have inputs that correspond to its input pins,
and outputs that correspond to its output pins. Depending on how
detailed an emulation you want to provide, you may or may not want to
emulate (for one example) its address bus directly -- you may prefer to
simply have an array (or vector, etc.) available as its memory, and the
"address bus" will be implicit in the subscripts supplied to that array.

I'm not sure, but it sounds like your real question was about whether it
was a good idea to make the debugging class a friend of the
microprocessor class. While that's certainly a valid possibility, I
think I'd use inheritance:

class MPU_6502 {
// Note: incomplete, untested, etc.
protected:
char A, X, Y, F, SP;
short PC;
enum flags { carry=1,
zero=2,
IRQ_mask = 4,
decimal = 8,
BRK = 16,
OV = 64,
negative = 128
};
public:
reset() {
A=F=X=Y=0;
SP = 0xff; // ?
PC=0xFFFC;
}
SO() { F |= OV; }

// Add functions for IRQ, NMI, etc.
};

class ICE_6502 : public MPU_6502 {
// extra debug access here
};

This corresponds fairly closely to reality: the real 6502 provides only
certain specific access to the internals, but there is also such a thing
as a ICE (In-circuit emulator) that can be substituted for the real
processor, which also provides more access to processor internals. This
does require making most of the internals protected instead of private,
but IMO this is a fairly minor problem -- you're not dealing with a
large class hierarchy here.

From there, you're left with questions about the emulation you want to
provide. This includes both whether you emulate the processor bugs or
not, and the level of detail you want to provide. An emulator to play
Apple/Atari/Commodore games will generally be quite different from one
that lets you see how whether (for example you can use a clock signal
with a given amount of noise or not.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Immortal Nephi]

On Aug 30, 9:45*am, Jerry Coffin <[e-mail]:

In article <1872f022-3fc0-4ff6-bc94-
[e-mail]>, [e-mail]
says...

Jerry,

* *I have an idea how to design an object in a better way.

The first part of good design (OO or otherwise) is applying knowledge of
the domain, first acquiring that knowledge if necessary.

In this case, it looks to me like you're trying to create a design that
just doesn't work much like a real 6502 microprocessor did. For example,
you mention making the address bus available to external code via get
and set methods. On the 6502, the address bus was output-only, so an
emulator that took inputs on the address bus wouldn't be very accurate
at all.

An accurate emulation of a microprocessor starts with its data sheet.
Generally speaking, you have inputs that correspond to its input pins,
and outputs that correspond to its output pins. Depending on how
detailed an emulation you want to provide, you may or may not want to
emulate (for one example) its address bus directly -- you may prefer to
simply have an array (or vector, etc.) available as its memory, and the
"address bus" will be implicit in the subscripts supplied to that array.

I'm not sure, but it sounds like your real question was about whether it
was a good idea to make the debugging class a friend of the
microprocessor class. While that's certainly a valid possibility, I
think I'd use inheritance:

I want to thank you for a feedback how 6502 microprocessor
works. Fortunately, I have already written 6502 simulator as a real
6502 MPU chip. My test shows that Run() function processes address
bus, data bus, and internal registers once as one clock cycle. You
can execute Run() function many times as you wish so it processes each
clock cycle.
According to my 6502 research, my MPU_6502 object behaves as real
chip as 6502 simulator very accurately. Unlikely, other emulators
don't do process each clock cycle.

class MPU_6502 {
* * * * // Note: incomplete, untested, etc.
protected:
* * * * char A, X, Y, F, SP;
* * * * short PC;
* * * * enum flags { carry=1,
* * * * * * * * * * * * zero=2,
* * * * * * * * * * * * IRQ_mask = 4,
* * * * * * * * * * * * decimal = 8,
* * * * * * * * * * * * BRK = 16,
* * * * * * * * * * * * OV = 64,
* * * * * * * * * * * * negative = 128
* * * * };
public:
* * * * reset() {
* * * * * * * * A=F=X=Y=0;
* * * * * * * * SP = 0xff; * * *// ?
* * * * * * * * PC=0xFFFC;
* * * * }
* * * * SO() { F |= OV; }

* * * * // Add functions for IRQ, NMI, etc.

};

class ICE_6502 : public MPU_6502 {
* * * * // extra debug access here

};

Nice class design. It is much similiar as my written MPU_6502
class. Unfortunately, it does not work. If you want to define
MPU_6502 object and ICE_6502 object in main() function, inheritance is
not an answer because MPU_6502 object and ICE_6502 object have their
own copy of member variables.
You can create two base classes of MPU_6502 and ICE_6502. You
don't need inheritance. You define MPU_6502 object first and then
ICE_6502 object second. You need to put friend class ICE_6502 into
MPU_6502 class. You set up a pointer inside ICE_6502 class so
ICE_6502 class' member function can access MPU_6502 class' member
variables through a pointer.
Another programmer in this post mentioned differently. He does
not recommend friend. He thinks that ICE_6502 class should be base
and then MPU_6502 class should be derived through private
inheritance. I can't sustain their opinions to think if C++ OOP has a
better design.

Nephi

This corresponds fairly closely to reality: the real 6502 provides only
certain specific access to the internals, but there is also such a thing
as a ICE (In-circuit emulator) that can be substituted for the real
processor, which also provides more access to processor internals. This
does require making most of the internals protected instead of private,
but IMO this is a fairly minor problem -- you're not dealing with a
large class hierarchy here.

From there, you're left with questions about the emulation you want to
provide. This includes both whether you emulate the processor bugs or
not, and the level of detail you want to provide. An emulator to play
Apple/Atari/Commodore games will generally be quite different from one
that lets you see how whether (for example you can use a clock signal
with a given amount of noise or not.

--
* * Later,
* * Jerry.

The universe is a figment of its own imagination.

[asm23]

Ian Collins wrote:

Immortal Nephi wrote:

> I have an idea how to design an object in a better way. I would like
to give you
my thought example. Please let me know what you think if it is best
object design.

Can you fix your like wrap and post again? This is very had to follow.

I agree with you, it's hard to read.

[tony_in_da_uk]

On Aug 30, 11:53 am, Immortal Nephi <[e-mail]>
wrote:

This MPU_6502 object can be reused to the client users.
What happen if programmers want to create another object which
it is called MPU_6502_Debug. This MPU_6502 object guards against
MPU_6502_Debug from accessing internal registers
using Set() and Get() functions. MPU_6502_Debug object needs to find
a way how to obtain internal registers from MPU_6502 object.

The friend keyword may be the option so friend class
MPU_6502_Debug can be added...

friend is appropriate here. It documents that a specific Debug object
is granted exceptional access. The derivation approaches mentioned in
other responses create an entirely different impression: that MPU_6502
is intended as a base class. On reading the code, a completely
different set of questions and impressions is raised regarding
MPU_6502's design and intended usage. In general, that's probably not
desirable - supporting some debugging functionality shouldn't be so
invasive, driving your OO model.

Tony