What is the meaning of public, protected, and private on class diagrams?
These are access modifiers. See the below:
https://en.wikipedia.org/wiki/Access_modifiers
Basically, "public" means that the item in question is available to anyone who has access to the object, "protected" means that it's available to the object itself and any subclasses, and "private" means it can be accessed only within the class itself. Some languages also add additional keywords, such as "internal" in C# (which basically means that it's available to any class in the same namespace; usually you use this if there's some class you use internally to your DLL that you don't want other people to use).
Related
the full sentence taken from the EJB3.2 specifications:
When interacting with a reference to the no-interface view, the client
must not make any assumptions regarding the internal implementation of
the reference, such as any instance-specific state that may be
present in the reference
I'm actually trying to understand what that actually mean and I was wondering if someone could kindly provide some examples.
EDIT:
The Above sentence is take from Section 3.4.4 Session Bean’s No-Interface View, maybe this info is helpful
When generating a no-interface view proxy, the EJB container must create a subclass of the EJB class and override all public methods to provide proxying behavior (like security, transactions).
You can get a reference to the bean with (eg. for passing it to another ejb):
NoInterfaceBean bean = ejbContext.getBusinessObject(NoInterfaceBean.class);
This returns a reference with a class-type that is the same as the bean class itself (normally if the EJB has a business interface it would return the interface class), but it is not a reference to an instance of NoInterfaceBean (but to that proxy class with the same name). Think of it as a reference to a pimped version of your bean, about which you
must not make any assumptions regarding the internal implementation
It's basically the same with "normal" EJB's. You know that there is some magic around your bean instance, but since you get the interface as class-type it's already clear that every class implementing the interface can have a different internal implementation.
So the specification emphasizes this difference at that point. Even if it looks like a reference to your concrete class it is none (as they say in the next paragraph of the specification JSR-000345 Enterprise JavaBeansTM 3.2 Final Release:
Although the reference object is type-compatible with the
corresponding bean class type, there is no prescribed relationship
between the internal implementation of the reference and the
implementation of the bean instance.
Does anybody knows why BlockData class doesn't directly implement IContent?
I know that during BlockData is being retrieve from database, proxy created by Castle implements IContent.
If StackOverflow isn't suitable place for this kind of a question, please move it.
Johan Björnfot at EPiServer explains some of the details in this post.
Excerpt:
"In previous versions of CMS was pages (PageData) the only content type that the content repository (traditionally DataFactory) handled. In CMS7 this has changed so now content repository (IContentRepository) handles IContent instances. This means that the requirement for a .NET type to be possible to save/load from content repository is that it implements the interface EPiServer.Core.IContent.
There are some implementations of IContent built into CMS like PageData and ContentFolder (used to group shared block instances) and it is also possible to register custom IContent implementations.If you look at BlockData though you will notice that it doesn’t implement IContent, how is then shared block instances handled?
The answer is that during runtime when a shared block instance is created (e.g. through a call to IContentRepository.GetDefault where T is a type inheriting from BlockData) the CMS will create a new .NET type inheriting T using a technic called mixin where the new generated subclass will implement some extra interfaces (including IContent)."
BlockData does implement IContent as it is intended to work both when added to another content item such as a PageData instance (a.k.a. Local Block), and as a standalone instance (a.k.a.Shared Block). In latter case the interface is added by using a mix-in though Castle Windsor so that it can be referenced.
The decision for this construct was based on wanting to be able to use the same rendering templates regardless if a block is local or shared. Therefor the choice stood between having a large number of empty properties on local blocks or the current solution using mixins. Both options were tested and mixins was selected as the preferred solution even though it's not a perfect one.
BlockData "does implement IContent", just do:
var myContent = (IContent)myBlock;
But, if you're by any chance handling a Block which itself is a property (not a ContentReference), that cast will throw an exception.
This will be true for 100% of all cases (... using Math.Round).
I was learning about the static class and static method.Then i came across the following line:
Only one copy of static member exists regardless of any no of instance of a class.
what does it actually mean?
It is in the msdn document http://msdn.microsoft.com/en-us/library/79b3xss3.aspx as follows:
A non-static class can contain static methods, fields, properties, or events. The static member is callable on a class even when no instance of the class has been created. The static member is always accessed by the class name, not the instance name. Only one copy of a static member exists, regardless of how many instances of the class are created. Static methods and properties cannot access non-static fields and events in their containing type, and they cannot access an instance variable of any object unless it is explicitly passed in a method parameter.
I think the statement is phrased poorly. What it's trying to mean is that static methods are associated with classes, rather than with object instances. There's only one copy of any given class at a time - and thus one copy of the data associated with any static method - whereas multiple object instances from a class can exist, on which nonstatic methods can operate.
I've read the entire Swift book, and watched all the WWDC videos (all of which I heartily recommend). One thing I'm worried about is data encapsulation.
Consider the following (entirely contrived) example:
class Stack<T>
{
var items : T[] = []
func push( newItem: T ) {
items.insert( newItem, atIndex: 0 )
}
func pop() -> T? {
if items.count == 0 {
return nil;
}
return items.removeAtIndex( 0 );
}
}
This class implements a stack, and implements it using an Array. Problem is, items (like all properties in Swift) is public, so nothing is preventing anyone from directly accessing (or even mutating) it separate from the public API. As a curmudgeonly old C++ guy, this makes me very grumpy.
I see people bemoaning the lack of access modifiers, and while I agree they would directly address the issue (and I hear rumors that they might be implemented Soon (TM) ), I wonder what some strategies for data hiding would be in their absence.
Have I missed something, or is this simply an omission in the language?
It's simply missing at the moment. Greg Parker has explicitly stated (in this dev forums thread) that visibility modifiers are coming.
Given that there aren't headers, the standard Objective-C tricks won't work, and I can't think of another trick to limit visibility that doesn't involve lots of bending over backwards. Since the language feature has been promised I'm not sure it's worth any big investment.
On the bright side since this feature is in flux, now is a great time to file a radar and influence how it turns out.
Updated answer for future reference.
From Apple's documentation:
Access Levels
Swift provides three different access levels for
entities within your code. These access levels are relative to the
source file in which an entity is defined, and also relative to the
module that source file belongs to.
Public access enables entities to
be used within any source file from their defining module, and also in
a source file from another module that imports the defining module.
You typically use public access when specifying the public interface
to a framework.
Internal access enables entities to be used within any
source file from their defining module, but not in any source file
outside of that module. You typically use internal access when
defining an app’s or a framework’s internal structure.
Private access
restricts the use of an entity to its own defining source file. Use
private access to hide the implementation details of a specific piece
of functionality. Public access is the highest (least restrictive)
access level and private access is the lowest (or most restrictive)
access level.
As a matter of fact I was delighted Swift finally adopted static typing so conforming to the theory for code with optimal OO properties, still the fall of the headers breaks the very meniang of Object Orienting programming, namely encapsulation. A way out would be like for Eiffel to automaticaly extract the headers but without specifying which are the public interfaces and which the private ones, it would be wortheless. I am really lambasted at this move of Apple's.
Does Encapsulation is information Hiding or it leads to information hiding??
As we say that Encapsulation binds data and functions in a single entity thus it provides us control over data flow and we can access the data of an entity only through some well defined functions. So when we say that Encapsulation leads to abstraction or information hiding then it means that it gives us an idea which data to hide and which data to show to users... coz the data that users cant access can be hidden from them thus encapsulation gives us a technique to find out what data to be hidden and what should be visible... Is this concept correct??
And what is the difference between information hiding and abstraction??
Possible duplicate of the this
public class Guest {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
See the above code, we have encapsulated the String name, we provide the access to it through public methods.
Say we have created object of Guest called guest. Then the following will be illegal.
System.out.println("Guests name : "guest.name);
Access through public methods is what can only be done.
guest.getName();
Benefits of Encapsulation:
The fields of a class can be made
read-only or write-only.
A class can have total control over
what is stored in its fields.
The users of a class do not know how
the class stores its data. A class
can change the data type of a field,
and users of the class do not need
to change any of their code.
Encapsulation means hiding the implementation
Abstraction means providing blueprint about the implementation
Data Hiding means controlling access to DataMember or attributes
Information is a more general term, hence, i believe, to say Encapsulation is Information hiding, will not be appropriate.
I would say Encapsulation is Data Hiding.
Encapsulation means ...
Combining an Object's State & behavior (that operates on that State), in one single unit.
This closely mimics a real world Object.
Hiding & Securing Object's State from accidental external alterations by providing a well-defined, controlled access (through behaviors).
In Java, the definition can be detailed out as ...
In Java, Classes and Enums are single units for implementing encapsulation. State is defined using variables (primitives, references to objects), and behavior using methods.
Data Hiding is achieved using private access specifier on variables (so that no one can access them from outside).
Controlled Access is achieved by providing Getters / Setters and/or business logic methods. Both Setters and other State affecting methods should have boundary condition checks for keeping the State logically correct.
Encapsulation talks about hiding data into something and give it a name ( private data members in a class - Car) and binding behavior methods with it which will mutate or provide access to those data variables.
Abstraction provides perspective of the client in abstract terms. As a concept or idea. Car is concrete entity where as Drivable, Trackable(which has position and can be tracked down) can be abstraction for Car for different clients.
You can check some real life examples of Abstraction and Encapsulation here.
Encapsulation is a technique used for hiding properties & behavior of an object.
Abstraction refers to representing essential features.
Encapsulation - Work complete and door permanently closed. Get work benefits through method name.
Abstraction - Work started and door temperately closed. Open and change work using overriding Key.
Both these OOP principles involve information hiding but are different.
Encapsulation involves restricting the direct access to the variables of the class by making them private and giving public getters and setters to access them.
Purpose: This is done so that the members of the class cannot be accidentally manipulated (and thus corrupted) from outside.
Abstraction involves exposing only the relevant details to the caller while hiding other details (details of implementation). The client does not need to bother about implementation which may change later. Example: The caller will call the add method of List, the implementation of which may be ArrayList today but may change to LinkedList tomorrow.
Purpose: This provides flexibility that tomorrow the implementation can be changed. Also, it simplifies the design.