Monday, June 1, 2015

Java for C# developers: Access Modifiers

Access Modifiers

(Java for C# developers)

What is an access modifier?

An access modifier is a keyword, which specifies the visibility and the access to a member (field, method, property) or a class. Therefore, it defines the rules by which your API/classes can be used and utilized - what can be changed, what should never change, what is internal and should not be exposed to anyone but the maintainer of the library, etc.

Why is it important?

When exposing your application to the world (i.e. - your colleagues, your clients) you must take care of protecting your classes and make them more robust. Here are some common cases, where taking a wrong decision can hurt you in the long term:

  • If a method is public everyone will start using it. This means, that it's harder for you to later hide this method. You cannot change what it's doing and you have to supported it happily ever after. (Note: there are ways to start deprecating methods, but it takes time and effort for everyone)
  • If a variable is public everyone has access to it and can easily modify it. This can change the behavior and correctness of your application.
  • If a variable is protected all inheriting classes will have access to it. This means, you have to keep it in the base class, but gives you the availability to provide special access to classes inheriting the base class.


In C# libraries are organized in namespaces and DLLs, whereas in Java they are organized in packages. We can assume that libraries/namespaces and packages are similar and compare the access modifier in this context.

Access modifiers are slightly different on classes and class member levels, so we'll compare them separately.


Access C# Java
default Defaults to internal - access limited to current assembly Defaults to package-private - access limited to the package
private Access limited only to containing class. Used for nested classes. Access limited only to containing class. Used for nested classes.
public No restriction on the access. No restriction on the access.

Access C# Java
default Defaults to private - access limited to current class Visible across the package, cannot be access from inheriting classes.
private Access limited to only current class. Access limited to only current class.
public No restriction on the access. No restriction on the access.
protected Visible in current and inheriting classes. Visible in current and inheriting classes.
internal Access limited to the current assembly. No such keyword. Similar to no modifier - i.e. package-private.

As you can see, C# and Java modifiers are not so different. They are almost equivalent and the same concepts are applied in both languages. Most notable difference is that the default member access is private in C# and package-private in Java, so if you're used to not writing access modifiers, you'd better start explicitly adding them to prevent code problems and protect your variables.

Rule of thumb

Set the most specific and limited access possible - don't expose more from your classes than you need to.

The rule of thumb in access modifiers is shared amongst all OOP languages. Expose just as much as required and protect everything else. This can give you the freedom to change the underlying implementation, data structures and rename fields/methods which are not visible. Don't allow easy break-in your functionality.


Friday, May 15, 2015

Everlive API Swagger


Swagger is now the defacto standard for documenting REST APIs - it's widely used, known and adopted. In most cases, you add comments and meta information to your APIs in your own code, and swagger can generate an API reference for it. It's not a static one though, not only you can see the definitions, parameters and etc. but you can even give it a try, which is awesome.


If you're using the Telerik Backend Services (a.k.a. Everlive) you may find this little project quite useful. By entering your API Key and Master Key it dynamically generates a Swagger API definition for your Content Types in Everlive. Therefore, you can easily test out stuff - add items, query items, check boundary cases like errors and etc - the best part is that you can do this without writing a single line of code.

Swagger + Everlive

The project generates dynamically a Swagger definition for an Application in the Telerik Backend Services. By providing your API and Master Keys the service extracts your Application's Metadata and generates a Swagger Definition with all your Content Types and Fields. The auto-generated content is then displayed in the nice Swagger UI. 

Give it a try and let me know what you think.