TITLE: Thoughts on adding public member functions


PROBLEM: bob@nemesis.pln.rboc.eds.com (Bob Reveal)

Our group is looking to implement reuse practices during our next project.  


RESPONSE: PJL p j l @graceland.att.com (Paul J. Lucas) 4 Nov 94

For my current project, I know the architecture and libraries
would have gone to hell in a hand-basket if everyone,
especially the inexperienced who are still C programmers and
who also have member-function-itis, were allowed to put stuff
in.  These people need to be protected from themselves.  A
little C++ knowledge is a disasterous thing.  


RESPONSE: BO billyoc@dpscon.uucp.netcom.com (Billy O'Connor)

I don't want to sound like a wise guy, but could you describe the
symptoms of member-function-itis?  

PJL:
	Overabundance of member-functions.  Have a problem?  Throw
	another member-function at it instead of thinking of what the
	class user is really trying to do.  Example from my own project:

		SCK:	I need a DialogItem's (x,y) coordinates.
		PJL:	Why?  What are you really trying to do?
		SCK:	I want to position one item relative to another.
		PJL:	Oh, so what you really want is for DialogItem to
			have another constructor that takes a DialogItem
			as an argument and positions itself relative to it.
		SCK:	Yeah...that'll work.

	The MFI-afflicted person would instead just add .X() and .Y()
	thus increasing the public interface.  The public interface
	should be as small as possible, but not smaller.  You really
	want to understand the big picture, tweak the _right_ things,
	and rebalance the universe.

BO: 

	I think I might have it.

PJL:

	Try electro-shock therapy: every time you add a member-function,
	jolt yourself.