encapsulation

I am wondering which one of these would be considered the cleanest or best to use and why. One of them exposes the a list of passengers, which let the user add and remove etc. The other hides the list and only let the user enumerate them and add using a special method. Example 1 class Bus { public IEnumerable<Person> Passengers { get { return passengers; } } private List<Passengers> passengers; public Bus() { passengers = new List<Passenger>(); } public void AddPassenger(Passenger passenger) { passengers.Add(passenger); } } var bus = new Bus1(); bus.AddPassenger(new Passenger()); foreach(var

Given a C API to a library controlling sessions that owns items, what is the best design to encapsulate the C API into RAII C++ classes? The C API looks like: HANDLE OpenSession(STRING sessionID); void CloseSession(HANDLE hSession); HANDLE OpenItem(HANDLE hSession, STRING itemID); void CloseItem(HANDLE hItem); Plus other functions that are useful for one of these types (Session, or Item) and map directly to C++ member functions of the relevant object. But they are not needed here. My main interest is in the construction and destruction of these objects, using RAII to manage a correct opening

What methods, practices and conventions do you know of to modularize C code as a project grows in size? Create header files which contain ONLY what is necessary to use a module. In the corresponding .c file(s), make anything not meant to be visible outside (e.g. helper functions) static. Use prefixes on the names of everything externally visible to help avoid namespace collisions. (If a module spans multiple files, things become harder., as you may need to expose internal things and not be able hide them with "static") (If I were to try to improve C, one thing I would do is make "static" the

I have a class with a number of static methods. Each one has to call a common method, but I'm trying not to expose this latter method. Making it private would only allow access from an own instance of the class? Protected does not seem like it would solve the problem here either. How do I hide do_calc from being called externally in a static context? (Leaving it available to be called from the first two static methods.) class Foo def self.bar do_calc() end def self.baz do_calc() end def self.do_calc end end First off, static is not really part of the Ruby jargon . Let's take a simple example:

" Abstraction and encapsulation are complementary concepts: abstraction focuses on the observable behavior of an object... encapsulation focuses upon the implementation that gives rise to this behavior... encapsulation is most often achieved through information hiding , which is the process of hiding all of the secrets of object that do not contribute to its essential characteristics." - Grady Booch in Object Oriented Analysis and Design Can you show me some powerfully convincing examples of the benefits of encapsulation through information hiding? The example given in my first OO class:

What's wrong with this? From objective, and functional standpoints? import sys class EncapsulationClass(object): def __init__(self): self.privates = ["__dict__", "privates", "protected", "a"] self.protected = ["b"] print self.privates self.a = 1 self.b = 2 self.c = 3 pass def __getattribute__(self, name): if sys._getframe(1).f_code.co_argcount == 0: if name in self.privates: raise Exception("Access to private attribute \"%s\" is not allowed" % name) else: return object.__getattribute__(self, name) else: return object.__getattribute__(self, name) def __setattr__(self, name, value): if sys.