From the structural perspective, next level after project, source folder, library and package is a class.
Class in Java and most other OO language is a happy place where the little ones feel them self at home. With the little ones I mean class members like methods and fields. They represent behavior/state.

The definition of the members is pretty strict in most of the OO languages.
For example in Java we define a class which is identified by a name. And inside this definition we have methods and fields (You can also define nested classes etc.. but I will skip this at the moment). There are special methods that hold the same name as the class. We call this methods Constructors. A method may have a name, return type and a list of parameters. This organization is strict and must be followed!

Not in Scala it don’t.

In Scala a class is also a place for the little ones and it also have a name but the way you define class and it members may variate.

The minimalistic definition of class is:

class Person

this representation is almost useless except when you start to play around with traites, but this I will cover in a different post.

So lets add some members – behavior and state to the old good Person.

class Person(firstName:String, lastName:String)

What you see right here is a primary constructor. It is a class member but with no explicit definition. You can also make this member private.

class Person private (firstName:String, lastName:String)

But this member is not only defined implicitly it also do some implicit stuff. It’s usual to store constructor parameters as private final fields. The notation above does actually this usual thing. This otherwise means that it defines three members – a constructor and two private final fields.
You can convert the private fields to public by defining them as vals.

class Person(val firstName:String, val lastName:String)

And this guys also may lose there immutability if they are defined as vars

class Person(var firstName:String, var lastName:String)

A class may also have a parent class and a constructor may call a super constructor.

class Person(firstName:String, lastName:String) extends Creature(firstName+lastName)

Wait aren’t constructors methods? Shouldn’t they define behavior? Well if you want to define a behavior/side effects, then you have to go an extra mile and create a scope (class body) and then you can just write down the behavior directly in there.

class Person(firstName:String, lastName:String){
 require(lastName!=nil)
 println(firstName + " " + lastName)
}

By the way Scala has a build in parameter validator require which throws IllegalArgumentException if you’v been bad.

Now in the class body you not only may define the behavior for primary constructor, but also other members.
So you also may define fields traditionally.

class Person(firstName:String, lastName:String){
 var age : Int
}

The age is a public field (btw. in Scala elements are public by default). A method may be defined in a class body as well but I will skip it, because I want to cover methods/functions/closure sometimes later, and in depth ;) .

What I still want to mention before I speculate about possible IDE support is auxiliary constructor. Scala do have a method overloading and as constructor is a method, it may be overloaded. There are still hard restrictions for constructor overloading in Scala. An auxiliary constructor must make direct or transitive (trough another constructor) call on primary constructor.

class Person private (firstName:String, lastName:String){
 def this() = this("Elvis", "Presley")
}

The example above demonstrates an auxiliary constructor that calls a private primary constructor and creates an Elvis imitator. The class is a complete bollocks, but I think you get the idea.

And we are still not done. A class may be abstract. This means that it has methods that provide no implementation, this also means that an abstract class should not be instantiated. An abstract class may be extended by other classes and this is pretty much useful for case classes. But what are case classes. Case classes are classes that are primarily used for pattern matching. And because of pattern matching you may define an abstract class sealed. Sealed class means, that extended case classes may only appear in the same file. I will cover pattern matching in another post, but what is still interesting in this post is class extension/inheritance.

What is class inheritance good for?

Well there are two main applications for inheritance:

1. If you extend a class you get his non private members. You may also override his members and than call them in your own implementation.
2. Inheritance is an IS-A relation, this means that the child class is of the same type as its parent. In an example above we could say Person is a Creature so if I need a Creature, I will also be satisfied with a Person, because person is a creature.

I may forbid inheritance by defining a class final.

Now I guess we are ready to talk about IDE support.

Well first of all how do we get to create a class?

Normally a class wizard creates a new file, but in Scala it is optional as we learned before in this post and in (Files and Folders). So feature complete wizard should provide following options:
1. What file you want to place it, a new one or a selected one.
2. Define package identifier
3. Define class name
4. Provide list of parameters for primary constructor.
5. Mark the class as abstract, sealed abstract, final or case class
6. Define class visibility
7. Define parent. By the way in Scala class may extend another non final class, abstract class or a trait. If extended class has a primary constructor wizard may guess how to invoke it or at least provide a todo and nil as parameters.
8. Define a list of mixins/traits. The trait order is important.

Now let’s think about visualizations:

Class outline should show all members of class itself, his parents and mixed in traits.
Primary constructor should be marked as such. Abstract methods also should be marked.

It is pretty complicated thanks to the usage of multiple traits and transitive inheritance relation.

Another interesting field of application is member representation conversion or refactoring. As you may represent the members in different ways, it should be possible to convert one representation in to other.

I sugest the list of possible IDE features is not complete but at this moment the post is long enough :)

Next post will be a step deeper into structural paradigm. It’s going to be all about functions/closures/methods

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you submit form:
Human test by Not Captcha

© 2011 Max Blog Suffusion theme by Sayontan Sinha