Code reviews

[suityou01]

Exactly - so for anything but the simplest class imaginable, if you don't want to duplicate code all over the place you will have smaller reusable methods. Those methods are not meant to be exposed to the outside world because they are for manipulating the internal state.
So if you make them public you are breaking encapsulation because the outside world is now not restricted to interact via the appropriate public api; now they can **** about with the internal state of that object unrestricted.

Yes, unless you don't use private methods, and just have whacking great spaghetti public methods. As long as they are declared in an interface def, you're good to go. Soupy is a visionary and so far ahead of his time.

Tune in next week for his episode on "Inheritance isn't necessary", or "Abstraction is just an overhead".

[suityou01]

DOH!!!! Sorry have fixed it, well spotted!!

[minestrone]

Yes, unless you don't use private methods, and just have whacking great spaghetti public methods. As long as they are declared in an interface def, you're good to go. Soupy is a visionary and so far ahead of his time.

Tune in next week for his episode on "Inheritance isn't necessary", or "Abstraction is just an overhead".

Inheritance should be avoided at all costs.

[suityou01]

Inheritance should be avoided at all costs.

[Unix]

Inheritance should be avoided at all costs.

I agree, composition is better.

[MyUserName]

Inheritance should be avoided at all costs.

Why do you think that?

[woohoo]

Almost all IDE's/editors allow you to easily navigate between method calls. Code becomes much more readable when you have smaller methods that are properly named i.e.

if (isCardVerified()) {

//do stuff
}

rather than repeating the perhaps complex code inside isCardVerified every time.

I agree with you but it could be argued in this example that IsCardVerified could be a public method on a class called CardVerification. CardVerification could be passed into your class in the constructor. This would enable this common code to be used through out your app and other apps. BUT I would only do this for code that would be reused out side of calling class.

[SpontaneousOrder]

So making all private data public would break encapsulation? Isn't that what I said?

Yes it would. I just mean that "encapsulating" data by making it private but then just adding a public mutator/accessor in front of it is not really encapsulation at all - it's a token gesture to make yourself feel better.

In those cases, if it weren't for java bean standards and things like that, you may as well just leave the data member public and not bother with the getter/setter. I'm not saying it's a bad thing to do - just that it isn't really a meaningful example of encapsulation.

[suityou01]

Why do you think that?

Because it marks things less flat.

[suityou01]

Yes it would. I just mean that "encapsulating" data by making it private but then just adding a public mutator/accessor in front of it is not really encapsulation at all - it's a token gesture to make yourself feel better.

In those cases, if it weren't for java bean standards and things like that, you may as well just leave the data member public and not bother with the getter/setter. I'm not saying it's a bad thing to do - just that it isn't really a meaningful example of encapsulation.

Indeed. In C#4 et seq you don't even declare accessors as it just does it all for you. No clearer supporting argument for what you say IMVHO.