Re: InsideOut - even tighter coupling

I'm just interested: how will methods access other private variables, and if you even want that in your code?

If you only use methods as accessors, then this is not a problem. but if your methods actually do something useful, they often need access to private variables. And then what?

I see a lot of nodes here on PM that treat methods as accessors only, which is defenitely not the case in good OOP, IMO.

Comment on Re: InsideOut - even tighter coupling

Replies are listed 'Best First'.
Re: Re: InsideOut - even tighter coupling by linux454 (Pilgrim) on Oct 13, 2003 at 14:13 UTC
However, good OOP code encapsulates all member variables with accessor/mutators. Great OOP code uses that encapsulation internally. There are few instances where direct access to private members are needed internally. In 9 out of 10 cases using an accessor/mutator internally will suffice. This practice allows your objects to be as flexible with regard to implementation internally as they are to external objects. The moral of this story. When writing your Class, treat your class as you would an external class. It all comes back to the Golden Rule: Treat others as you want to be treated. hmm... It even works for programming =] This approach leads to a more flexible Object Model, and when implementations change you will find yourself typing less code. ( Because we all know that programmers are lazy =] )	[reply]
Re^3: InsideOut - even tighter coupling by Aristotle (Chancellor) on Oct 13, 2003 at 17:45 UTC
This practice allows your objects to be as flexible with regard to implementation internally as they are to external objects. Indeed. In particular, it makes a subclass author's life much easier when an object doesn't rely on its own implementation structure any more than absolutely necessary. Makeshifts last the longest.	[reply]
Re: Re: InsideOut - even tighter coupling by MidLifeXis (Monsignor) on Oct 15, 2003 at 17:10 UTC
That is actually what I am working on, how tightly can you (or, I guess, can I) couple variables to their accessors / mutators, and still be able to make it usable. I am especially interested in avoiding name collisions on the private variable stash when using inheritance. I think this is going to do the trick. The problem I ran into was with the DESTROY method. That issue was cleared up by running a registration method on the private variables. I will try using this in a couple of small things, and see how well it scales for me.	[reply]


"be consistent"
	PerlMonks