In my previous post  I discussed the case for Properties and the basics of how they work. In this post I will dive into the specific workings of Properties in Sgine and how to use the various features it provides. This post is all about Properties in Sgine for use primarily with Scala but the concepts and ideas are applicable to Java as well. Properties provide the future of object architecture and beans should have been deprecated long ago.

Read the full story here: http://www.sgine.org/2010/09/beans-should-be-deprecated-future-of.html

While reading your post I finally realized that all developers are divided into two categories: first group which is more in love with artistic aspects and second group which is more in love with engineering aspects of software development. I belong to second one, and small details such as difference (and benefits) between beans and properties is absolutely irrelevant to me, while first group preferrs to have even the smallest details worked to perfection.To me, languages are just  tools and I don't care if they are not "perfect" as long as I can use them to make new creation "perfect", while second group I guess would like to make even tools themselves perfect even though it will not affect whether something created by using them is perfect itself.

I am not stating that either group is right or wrong, better or worse, just I guess saying that different people have different preferences and interests.

but I don't think the Property approach is a viable option in Java for one significant reason: single inheritance. The architecture you describe, extending all types of properties from the base Property class, will get impractically complex and difficult to maintain for all permutations of Property.

For example, if you want a Property that is non-null and 256-or-less characters, you would need to extend Property to generate NonNullProperty and then extend NonNullProperty to generate TwoFiftySixCharacterProperty. Should a Property that is 256-or-less characters be required that can take null values, you would need to essentially duplicate the TwoFiftySixCharacterProperty class and extend directly from Property. As you can see, this will get out of hand quite quickly.

In another language that supports multiple-inheritance, I could see the benefit of implementing such a strategy.

For example, if you want a Property that is non-null and 256-or-less characters, you would need to extend Property to generate NonNullProperty and then extend NonNullProperty to generate TwoFiftySixCharacterProperty. Should a Property that is 256-or-less characters be required that can take null values, you would need to essentially duplicate the TwoFiftySixCharacterProperty class and extend directly from Property. As you can see, this will get out of hand quite quickly.

Then don't do that.

Make a SuperDuperNullNotNullAnyLengthNumberValidatingUberProperty that you can configure when you build it.

Or: Property<String> myString = PropertyFactory.buildProperty(String.class, "initial value", NOTNULL, MINLENGTH, 5, MAXLENGTH, 10, REGEX, "[A-Z]+");

Wow, that was hard.

I like the idea. I like it for many of the reasons stated, notably being able to reuse logic as an aspect of the property (like change notification, etc.) rather than the thousands of lines of boiler plate we get code gen'd "for free" (yea, like a puppy...).

The dark side is, at least in my case, a bulk of my "beans" are JPA'd beans. So, they're not really eligible for this since neither the FIELD or PROPERTY technique can (readily) be used to populate them. I mean, I could boiler plate the setter/getter as wrappers for the Property calls, but -- dunno if that kills or cures, really.

So its one of those chicken/egg momentum things. If the idiom were first used early on, then we'd have all of this built in dependency for it (like we have now). But, now it's a bit far down the road, so uptake as a general purpose tool has many ancillary infrastructure costs.

Still a cool idea, and I'll keep it in mind.

For example, if you want a Property that is non-null and 256-or-less characters, you would need to extend Property to generate NonNullProperty and then extend NonNullProperty to generate TwoFiftySixCharacterProperty. Should a Property that is 256-or-less characters be required that can take null values, you would need to essentially duplicate the TwoFiftySixCharacterProperty class and extend directly from Property. As you can see, this will get out of hand quite quickly.

Then don't do that.

Make a SuperDuperNullNotNullAnyLengthNumberValidatingUberProperty that you can configure when you build it.

Or: Property<String> myString = PropertyFactory.buildProperty(String.class, "initial value", NOTNULL, MINLENGTH, 5, MAXLENGTH, 10, REGEX, "A-Z+");

Wow, that was hard.

I like the idea. I like it for many of the reasons stated, notably being able to reuse logic as an aspect of the property (like change notification, etc.) rather than the thousands of lines of boiler plate we get code gen'd "for free" (yea, like a puppy...).

The dark side is, at least in my case, a bulk of my "beans" are JPA'd beans. So, they're not really eligible for this since neither the FIELD or PROPERTY technique can (readily) be used to populate them. I mean, I could boiler plate the setter/getter as wrappers for the Property calls, but -- dunno if that kills or cures, really.

So its one of those chicken/egg momentum things. If the idiom were first used early on, then we'd have all of this built in dependency for it (like we have now). But, now it's a bit far down the road, so uptake as a general purpose tool has many ancillary infrastructure costs.

Still a cool idea, and I'll keep it in mind.

C# provides an example. To me having properties isn't that big of a deal, but that's just me.

Then don't do that.

Make a SuperDuperNullNotNullAnyLengthNumberValidatingUberProperty that you can configure when you build it.

Or: Property<String> myString = PropertyFactory.buildProperty(String.class, "initial value", NOTNULL, MINLENGTH, 5, MAXLENGTH, 10, REGEX, "A-Z+");

Wow, that was hard.

Eh. I tend to avoid the "silver bullet" approach of one SuperDuper anything. :-) As for the PropertyFactory approach, that's much better than building an inheritance heirarchy, I agree. However, if you're going to go through the lengths to do something like that I'd much rather use some type of validation framework (Spring Validators, for example) that can more easily be de-coupled from the object on the fly.

So its one of those chicken/egg momentum things. If the idiom were first used early on, then we'd have all of this built in dependency for it (like we have now). But, now it's a bit far down the road, so uptake as a general purpose tool has many ancillary infrastructure costs.

Still a cool idea, and I'll keep it in mind.

I agree completely. If this had been the "standard" from the start, we'd have the framework already built (and perhaps even in the JDK) and we wouldn't have to consider the pain refactoring existing code. If Java were to standardize an out-of-the-box solution that would satisfy encapsulation without the necessity of getter/setter methods littering the code, it would be a big improvement.

I'll wholely admint, however, that I am not ready to relinquish the use of JavaBeans... there are too many benefits.

Then don't do that.

Make a SuperDuperNullNotNullAnyLengthNumberValidatingUberProperty that you can configure when you build it.

Or: Property<String> myString = PropertyFactory.buildProperty(String.class, "initial value", NOTNULL, MINLENGTH, 5, MAXLENGTH, 10, REGEX, "A-Z+");

I would do neither.  A composition approach would be preferred as it would be unlimited in extensibility:

import java.util.ArrayList;
import java.util.List;

interface Property<E>
{
  void set(E value) throws ValidationException;
 
  E get();
}

class BasicProperty<E> implements Property<E>
{
  private E value;

  public E get()
  {
    return value;
  }

  public void set(E value) throws ValidationException
  {
    this.value = value;
  }
}

class ValidatingProperty<E> implements Property<E>
{
  private final Property<E> wrapped;
  private final List<Validation<? super E>> validations;
 
  ValidatingProperty()
  {
    this(new BasicProperty<E>(), new ArrayList<Validation<? super E>>());
  }
 
  ValidatingProperty(List<Validation<? super E>> validations)
  {
    this(new BasicProperty<E>(), validations);
  }
 
  ValidatingProperty(Property<E> wrapped, List<Validation<? super E>> validations)
  {
    this.wrapped = wrapped;
    this.validations = validations;
  }
 
  public ValidatingProperty<E> add(Validation<? super E> validation)
  {
    this.validations.add(validation);
    
    return this;
  }
 
  public E get()
  {
    return wrapped.get();
  }

  public void set(E value)
  {
    for (Validation<? super E> validation : validations)
    {
      validation.test(value);
    }
    
    wrapped.set(value);
  }
}

interface Validation<E>
{
  void test(E value) throws ValidationException;
}

class ValidationException extends RuntimeException
{
  /** serial id */
  private static final long serialVersionUID = 1L;
 
  ValidationException(String message)
  {
    super(message);
  }
}

class NonNullValidation<E> implements Validation<E>
{
  public void test(E value) throws ValidationException
  {
    if (value == null) throw new ValidationException("value cannot be null");
  }
}

class StringLengthValidation implements Validation<String>
{
  private final int length;
 
  StringLengthValidation(int length)
  {
    this.length = length;
  }
 
  public void test(String value) throws ValidationException
  {
    if (value != null && value.length() > length) {
      throw new  ValidationException("value is longer than "
        + length + " characters");
    }
  }
}

An example of use:

public static void main(String[] args)
{
  Property<String> property = new ValidatingProperty<String>()
    .add(new NonNullValidation<String>())
    .add(new StringLengthValidation(5));
      
  property.set(null);
      
  property.set("too long");
      
  property.set("abc");
      
  System.out.println(property.get());

}

I think that the multiple inheritance problem can be avoided using the decorator pattern in most cases.

I prefer Groovy approach for properties.

You can use Groovy like properties in Java using AspectJ.

I agree with Xavier, instead so much IoC artifactory I would like AspectJ more mainstream, more standard and more integrated on java compilation.

The problem of AspectJ is it is too much decoupled, let me explain, anybody would like to add some kind of value range check with a simple annotation alongside the attribute without sacrifying object lifecycle, in AspectJ you must "bind" this range check in a different class artifact, the associated aspect.

Non-coupled aspects are fine when you need extrem separation of cross-cutting concerns, but in this case of range checking there is nothing wrong if range check is declared in the attribute of the main class as usual in IoC, in IoC the IoC engine performs the checkings in an inherited class created on the fly (for instance with CGLib), this is the reason why you cannot use straight "new" sentences. Yes I know Spring can use AspectJ under the hood if you need the "new" calls again, but in this case you don't have very much control of aspects used by Spring (am I wrong?).

What I want with a simple example:

@ValidRange(lower = 0, upper = 130)

private int age;

In some place (XML registry or similar) @ValidRange is associated to a concrete, user defined, aspect, this aspect knows how to check the range of an integer attribute but it has not clue about the classes to be applied (this is not the typical declaration of aspects). When javac compiles this class automatically checks if the associated aspect exists, then is compiled (if needed) and automatically new binding bytecode is injected to the main class to the get/set methods to performs value range checking calling the aspect class USER DEFINED (this is very important for me).

Does something similar already exist? Spring AOP?

The advantage of an aspect oriented implementation is that, in theory, you get both compliance with the existing Bean concept along with the first class Property nature of the slot.

C# properties (as I understand them) aren't related to this concept at all. They're more elegant than Java properties, specifically because they have first class language support, but the concept is not that same as what is being discussed here. If you wanted a "validated" C# property, you're burdened having to update and manage all of the setter/getters individually, rather than having a first class Property object to work with.

The AoJ concept is no different than what is mentioned here, simply the management is more transparent to the user, since the framework handles the work. The only potential downside is that you don't have actual, direct access to the Properties themselves, since they're managed all in the background.

Rather than calling obj.property.set("new"), you call obj.setProperty("new"), and the aspect framework can intercept that and do any logic upon the argument before letting the actual setter fire. Overall the code is similar in the end, just the wiring is different.

And this is more than validation. It can also be conversion or side effects. Validation is "check if everything is uppercase", vs conversion is "force everything to uppercase", as well as the changelisteners.

But the key takeaway is that properties are not simply slots holding values, they're active, first class managers of state change and retrieval, a responsibility normally delegated to the class itself. To me, that's the novelty represented here as I had not thought of them like that before.

The advantage of an aspect oriented implementation is that, in theory, you get both compliance with the existing Bean concept along with the first class Property nature of the slot.

C# properties (as I understand them) aren't related to this concept at all. They're more elegant than Java properties, specifically because they have first class language support, but the concept is not that same as what is being discussed here. If you wanted a "validated" C# property, you're burdened having to update and manage all of the setter/getters individually, rather than having a first class Property object to work with.

The AoJ concept is no different than what is mentioned here, simply the management is more transparent to the user, since the framework handles the work. The only potential downside is that you don't have actual, direct access to the Properties themselves, since they're managed all in the background.

Rather than calling obj.property.set("new"), you call obj.setProperty("new"), and the aspect framework can intercept that and do any logic upon the argument before letting the actual setter fire. Overall the code is similar in the end, just the wiring is different.

And this is more than validation. It can also be conversion or side effects. Validation is "check if everything is uppercase", vs conversion is "force everything to uppercase", as well as the changelisteners.

But the key takeaway is that properties are not simply slots holding values, they're active, first class managers of state change and retrieval, a responsibility normally delegated to the class itself. To me, that's the novelty represented here as I had not thought of them like that before.

I agree C# properties are different than validated properties, but I'm not convinced of the value of validated properties. My bias is to towards using validation framework to keep validation separate. Having used XML Schema validation in various forms, often it causes more trouble than it's worth. I tend to work in a service integration enviroment, so making assumptions a string has a max length of X characters often ends up being a complete pain. In theory, I like the idea of built-in property validation, but in practice it oftens ends up being too heavy.

That's my own jaded opinion from getting burned by third party API. For internal development, I see the value of validated properties.

I agree C# properties are different than validated properties, but I'm not convinced of the value of validated properties. My bias is to towards using validation framework to keep validation separate. Having used XML Schema validation in various forms, often it causes more trouble than it's worth. I tend to work in a service integration enviroment, so making assumptions a string has a max length of X characters often ends up being a complete pain. In theory, I like the idea of built-in property validation, but in practice it oftens ends up being too heavy.

I agree with this whole-heartedly.  When I first started doing distributed development, I though that I should use validation at the gate.  I then started to learn that often the business rules weren't as black-or-white as I was initially told and that having it was a pain to have to implement the more complicated logic in something like a schema.

Then I came to understand that even using schema validation for basic stuff like structure wasn't such a great idea.  The kinds of error messages you get out of schema validation are usually worthless to the person who recieves them.  They are obtuse and often refer to things that aren't the actual issue but happen to be near the issue.

In my most recent largescale effort related to this, I ended up not using schema validation at all.  I set my parser/binder to not only make everything optional, I also told it to ignore elements it did not understand.  I then created explicit checks in the code with specific meaningful error messages like: "name is required"  It didn't eliminate all obfuscated error messages but minimized them to only those where the xml was truly mangled.

I agree C# properties are different than validated properties, but I'm not convinced of the value of validated properties. My bias is to towards using validation framework to keep validation separate. Having used XML Schema validation in various forms, often it causes more trouble than it's worth. I tend to work in a service integration enviroment, so making assumptions a string has a max length of X characters often ends up being a complete pain. In theory, I like the idea of built-in property validation, but in practice it oftens ends up being too heavy.

I agree with this whole-heartedly.  When I first started doing distributed development, I though that I should use validation at the gate.  I then started to learn that often the business rules weren't as black-or-white as I was initially told and that having it was a pain to have to implement the more complicated logic in something like a schema.

Then I came to understand that even using schema validation for basic stuff like structure wasn't such a great idea.  The kinds of error messages you get out of schema validation are usually worthless to the person who recieves them.  They are obtuse and often refer to things that aren't the actual issue but happen to be near the issue.

In my most recent largescale effort related to this, I ended up not using schema validation at all.  I set my parser/binder to not only make everything optional, I also told it to ignore elements it did not understand.  I then created explicit checks in the code with specific meaningful error messages like: "name is required"  It didn't eliminate all obfuscated error messages but minimized them to only those where the xml was truly mangled.

I know that exact feeling! Glad to see I'm not the only one who got bitten by the same issue. Perhaps in the future, software development will change enough that we can actually trust business partners to follow the schema they publish. It would also be nice for business partners to provide sufficient warning a service is going to change instead of letting it all blow up at 2am, resulting in everyone rushing into the office to fix the issue.

I agree C# properties are different than validated properties, but I'm not convinced of the value of validated properties.

I just want to clarify, that while Validation is an application of these first class Properties, it's not the only use. To me, the concept of an active, first class, reusable Property logic (whatever that logic may be) is the interesting take away from all of this.