View Single Post
  #5   Spotlight this post!  
Unread 03-02-2009, 08:38
JamesBrown JamesBrown is offline
Back after 4 years off
FRC #5279
Team Role: Engineer
 
Join Date: Nov 2004
Rookie Year: 2005
Location: Lynchburg VA
Posts: 1,277
JamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond reputeJamesBrown has a reputation beyond repute
Re: why encapsulation is required?

From Wikipedia:

Encapsulation is the hiding of information. C++ implements encapsulation by allowing all members of a class to be declared as either public, private, or protected. A public member of the class is accessible to any function. A private member is accessible only to functions that are members of that class and to functions and classes explicitly granted access permission by the class ("friends"). A protected member is accessible to members of classes that inherit from the class in addition to the class itself and any friends.

The OO principle is that all of the functions (and only the functions) that access the internal representation of a type should be encapsulated within the type definition. C++ supports this (via member functions and friend functions), but does not enforce it: the programmer can declare parts or all of the representation of a type to be public, and is allowed to make public entities that are not part of the representation of the type. Because of this, C++ supports not just OO programming, but other weaker decomposition paradigms, like modular programming.

It is generally considered good practice to make all data private or protected, and to make public only those functions that are part of a minimal interface for users of the class. This hides all the details of data implementation, allowing the designer to later fundamentally change the implementation without changing the interface in any way




In general whenever you are writing an API, or any interface for other people to use encapsulation is a good practice. without encapsulation teams would have to rewrite their code every time WPILib made changes to a function that they use. With encapsulation if the inputs and outputs to a function remain the same then WPILib can be changed without effecting teams.
__________________
I'm Back


5279 (2015-Present)
3594 (2011)
3280 (2010)
1665 (2009)
1350 (2008-2009)
1493 (2007-2008)
1568 (2005-2007)