Java/Encapsulation - Revision history

Admin: /* Junk */

2017-06-21T14:36:31Z

Junk

← Older revision		Revision as of 14:36, 21 June 2017
Line 50:		Line 50:
	* Minimal - keep it simple.		* Minimal - keep it simple.


			==Flags==

			{{CSFlag}}

	[[Category:Java]]		[[Category:Java]]
	[[Category:OOP]]		[[Category:OOP]]
	[[Category:Encapsulation]]		[[Category:Encapsulation]]

Admin at 14:36, 21 June 2017

2017-06-21T14:36:03Z

@@ Line 1: / Line 1: @@
 ==What is encapsulation?==
@@ Line 4: / Line 6: @@
 This is a decision that must be made each time a new class, variable, or method is created - do we make it public, private, or protected?
 If we need to decide on what to expose to the outside world, what to keep public versus private versus protected, use this rule of thumb:
@@ Line 11: / Line 21: @@
 If you find that it's difficult to thoroughly test a class, then the class may be doing too much. Splitting the class up using composition can make the individual units more testable.
-As Josh Bloch states in his Effective Java book [http://www.oracle.com/technetwork/articles/javase/bloch-effective-08-qa-140880.html]:
+As Josh Bloch, creator of the Collections API, stated in an interview [http://www.oracle.com/technetwork/articles/javase/bloch-effective-08-qa-140880.html]:
 {{Quote|
@@ Line 25: / Line 35: @@
 - Josh Bloch
 }}
 ==Junk==
-A few heuristics:
+A few other heuristics:
 * Visibility of system status - keep status of things visible to users.
 * Match between system and world - keep verbiage and symbols system-oriented.

Admin at 14:34, 21 June 2017

2017-06-21T14:34:36Z

← Older revision		Revision as of 14:34, 21 June 2017
Line 1:		Line 1:
	~~Encapsulation: public/private.~~		==What is encapsulation?==

	~~Deciding~~ what we expose to the outside world, ~~versus~~ what we keep protected, ~~versus what we keep private~~:		Encapsulation is the idea that code - both methods and classes - should hide or abstract away detail.

			This is a decision that must be made each time a new class, variable, or method is created - do we make it public, private, or protected?

			If we need to decide on what to expose to the outside world, what to keep public versus private versus protected, use this rule of thumb:

	''Always make everything as private as possible.''		''Always make everything as private as possible.''

	If you find that it's difficult to thoroughly test a class, then the class may be doing too much. Splitting the class up using composition can make the individual units more testable.		If you find that it's difficult to thoroughly test a class, then the class may be doing too much. Splitting the class up using composition can make the individual units more testable.

			As Josh Bloch states in his Effective Java book [http://www.oracle.com/technetwork/articles/javase/bloch-effective-08-qa-140880.html]:

			{{Quote\|
			I can be somewhat fickle, so my favorite rules might change if you ask me on another day, but today I'll go with Item 13, "Minimize the accessibility of classes and members," and Item 15, "Minimize mutability." Both of these rules transcend any particular programming language.

			The first (minimize accessibility of classes and members) tells you to hide information to the maximum extent feasible. This principle, due originally to David Parnas, is one of the most fundamental tenets of good programming. If you hide information, you are free to change it without risking harm to the system. Information hiding decouples the components of the system, allowing them to be developed, tested, optimized, used, understood, and modified in isolation.

			Item 15 (minimize mutability) tells you to keep the state space of each object as simple as possible. If an object is immutable, it can be in only one state, and you win big. You never have to worry about what state the object is in, and you can share it freely, with no need for synchronization. If you can't make an object immutable, at least minimize the amount of mutation that is possible. This makes it easier to use the object correctly.

			So when should you break the rules? To paraphrase Orwell, you should break them when they'd result in code that is "outright barbarous." As a simple example, Item 25 says, "Prefer lists to arrays." So why does the values method present on every enum type return an array? Because the most common use of this method is to iterate over the elements of its return value, and '''it's much cheaper to iterate over an array than any List implementation.''' With the for-each construct, the code to iterate is the same either way.


			- Josh Bloch
			}}

	==Java==		==Java==

Admin at 18:31, 18 June 2017

2017-06-18T18:31:50Z

← Older revision		Revision as of 18:31, 18 June 2017
Line 40:		Line 40:
	* Accelerators - things unseen by novice users, allow speeding up interaction by expert users.		* Accelerators - things unseen by novice users, allow speeding up interaction by expert users.
	* Minimal - keep it simple.		* Minimal - keep it simple.


			[[Category:Java]]
			[[Category:OOP]]
			[[Category:Encapsulation]]

Admin at 18:30, 18 June 2017

2017-06-18T18:30:46Z

← Older revision		Revision as of 18:30, 18 June 2017
Line 7:		Line 7:
	If you find that it's difficult to thoroughly test a class, then the class may be doing too much. Splitting the class up using composition can make the individual units more testable.		If you find that it's difficult to thoroughly test a class, then the class may be doing too much. Splitting the class up using composition can make the individual units more testable.

			==Java==

			Encapsulation happens with fields or with members in Java. You can make fields and members private, protected, or public. By default, methods and fields of a class are private.

			'''Private''' means only instances of this class can access this method. No one else will be able to see the interface - not even child classes.

			'''Protected''' means instances of this class, as well as instances of child classes, can see the interface - but no one else can see it.

			'''Public''' means anyone who wants can walk up and do whatever they would like with your variable.


			==Junk==

	A few heuristics:		A few heuristics:

Admin: Created page with "Encapsulation: public/private. Deciding what we expose to the outside world, versus what we keep protected, versus what we keep private: ''Always make everything as private..."

2017-06-18T18:27:16Z

Created page with "Encapsulation: public/private. Deciding what we expose to the outside world, versus what we keep protected, versus what we keep private: ''Always make everything as private..."

New page

Encapsulation: public/private.

Deciding what we expose to the outside world, versus what we keep protected, versus what we keep private:

''Always make everything as private as possible.''

If you find that it's difficult to thoroughly test a class, then the class may be doing too much. Splitting the class up using composition can make the individual units more testable.

A few heuristics:
* Decomposition
* Abstraction
* Subset identification
* Information hiding
* Virtual structuring
* Modularity
* Separating policy and mechanism
* Hierarchy

A few more heuristics:
* Visibility of system status - keep status of things visible to users.
* Match between system and world - keep verbiage and symbols system-oriented.
* User control - allow users ability to leave unwanted state.
* Consistency - maintain consistency across interfaces.
* Error prevention - try and anticipate and prevent errors.
* Recognition, not recall - make things visible, not things they have to retrieve
* Flexibility - things should be flexible across situations
* Accelerators - things unseen by novice users, allow speeding up interaction by expert users.
* Minimal - keep it simple.