Discussions

News: Component Oriented Software - Java Perspectives

  1. A new paper on the recently launched softwarereality.com introduces the concept of Component-Oriented software from a Java perspective. It provides a high level description of the direction and momentum behind Java, its associated architectures, and to show where Java as a programming language could be heading.

    Components are an over-used word in the Java language, and there is often confusion about where the classification begins and ends. This paper tries to put some flesh on the bones and explain how Java programming language features and architectures relate to Component-Oriented concepts.

    In this discussion the paper makes a comparison between Java, C++ and .Net and takes a look at the evolution of the languages.

    The paper concludes that languages develop by moving closer to the solutions, but evolve by moving closer to the problems. It further concludes that Java as a language has stagnated by focusing too much on moving closer to solutions and needs to make greater efforts in moving closer to the problems.

    Check out this great article written by Robin Sharp, at
    http://www.softwarereality.com/programming/component_oriented.jsp

    Threaded Messages (31)

  2. well, i don't think this "paper" added any flesh or bones to anything... just a few vague thoughts on how the author imagines "component oriented" programming to be so much different from an object oriented approach.

    imho his argument is really thin, his suggested extensions to the java language unneccesary (what does it exactly save you if you define a "module" vs a plain old interface?)... about "types": perhaps C# saves you from typing a few get/set methods, but that's hardly a major advance, in fact with most IDEs thats a trivial task anyway...

    aspects on the other hand are really useful, but that's not news... (and also, not something that C# or the MS CLR supports natively).

    as far as the "comparison" of java/.net/c++ in the paper goes, well... where is it? :) was it the part that calls c and c++ a "functional language"?
  3. And your point would be..?

    Remember this is a web-based article we're talking about. I think the item you are looking for is called a "book".

    Seriously though, this article raises some interesting issues that definitely warrant further discussion. Why not concentrate on what is in the article, instead of griping about what you would like it to have said?
  4. the point i was trying to make, is that imho, the article raises no interesting questions... the author's suggestions on evolving java are nothing more than syntactic sugar that solves marginal issues (eg. not having to type get/set).

    using aspects is probably the only valid and important point raised in the article, but it's hardly new or surprising - and not inherently supported by any of the languages he claims to compare.

    but if you see anything warranting further discussion, please do point it out :)
  5. Robin Sharp makes a few interesting points in her discussion of Component-Oriented software. Primarily, she criticizes the Java community for not recognizing some of the advances C# had made and for becoming 'self-congratulatory' and 'lazy'.

    While I agree that making events and properties first class language constructs is a good decision, I do not believe that 'C# has leapfrogged Java'. C# embodies many of the lessons learned in the evolution of Object Pascal or Delphi. Properties, events, and a strong component model have been part of Delphi since 1995. Most of these ideas were embedded in the Java bean model, years ago.

    I think that it is important that the Java community remains open to new ideas (even from the evil empire) and avoids falling into a self-congratulatory stupour. However, believing that C# is really a signficant evolutionary step away from Java is unrealistic. Probably the most important idea to take away from C# and for that matter Delphi (Hejlsberg), is the importance of providing component containers and the infrastructure (linguistic, IDE) needed to easily build them.

  6. personally i consider AOP efforts (like AspectJ) and the new metadata JSR to be key in being able to fundamentally improve the separation of various concerns - from architecture to deployment.

    many important independent research efforts made their way into the java community process (think pizza/GJ -> JSR14, Matt Welsh's NBIO -> java.nio) - i wouldn't exactly call this "stagnation".

  7. The idea of 'API-bloom' is an important one and this is an issue that concerns me a great deal. It is important that a rproliferation of APIs does not dilute the platform.

    This is an area where .Net is at an advantage over Java - Microsoft has written their framework from the ground up, taking everything they know from the COM, VB and MFC worlds, and the experiences of the Java community to create a clean and consistent framework.

    Where we have raging debates about BMP ~and~ CMP Entity Beans, JDO, various OR mapping tools and a cloud of open source projects, the MS world has one elegant solution (and if you don't like the use of the word ~elegant~ try ADO.Net and tell me it isn't kind-of cool). And similarly with UI, particularly on the server-side, the Java-world has a disparate collection of technologies.
  8. I think you are very much right. MS Sure has a consistent and probably elegant way of handling server side code as well as persistence code.

    I say probably cause I have not personally used ADO.Net.

    But having said that I think the reasons are .Net is controlled by a single entity i.e. MS$

    On the other hand Java API come out of the JCP and hence there are bound to be many different ideas.

    Though yes java needs to learn from other languages and platforms; particularly C# and .Net.
    For one the way Web Forms are handled in .NET.
    Another is the way Persistence is handled in .NET.

    I think as far as persistence is concerned it should be seperated from RMI / IIOP as far as the programmers are concerned and one should be able to persist data without regard to type or location of database. These can be then specified in Descriptor files.

    Also if you look at EJB at the time of design usually one doesn't know if the EJB's are going to reside in one jvm or run under multiple jvm's. The way EJB stands today one either either specify them to have local or remote interfaces i.e change the code when the runtime environment changes. What would have been better is we either specify this in descriptor files or let the container find out whether this needs a local call or remote call which a lot of EJB 1.1 containers do in any case and optimise calls to EJB's in the same JVM by making local calls instead of Remote calls.
  9. Can anyone show a simple, concrete example of 'component oriented' programming in Java? How can 'aspect oriented' programming aid to this 'component oriented' programming?

    If .Net is used to implement the same example, it would make it easier to compare .Net and Java.



  10. It's important to understand what component-oriented programming (vs. object-oriented programming) is about. My article tries to make clear the separation that has been gradually clarifying over the last few years.

    In Java a component is a component is a bean. Following the bean specification is a sufficient condition for an object to be a component (set/get naming patterns, Serializable, void constructors etc). I for many years wrote beans that were both data and architecture, and used self-disciple to keep then two separate.

    In the literature this view has become outdated and has been replaced by a stricter distinction between types and modules (data and architecture, product and production, sausage and sausage machine).

    The reason for this is the recognition that in order to reduce API bloom it's necessary to make the same data available to different architectures. For example it would have been nice to migrate your Local EJB Beans to JDO, but as we all know because the architecture is tied to the data that isn't possible.

    Microsoft has a advantage because having (explicitly) made this distinction they can migrate their persistence architectures whilst us Java bods are left dragging out knuckles through the mud, wondering how to get out Local EJBs to JDO objects.

    Hope this helps clarify the situation.

    Robin
  11. This is an area where .Net is at an advantage over Java - >Microsoft has written their framework from the ground up, >taking everything they know from the COM, VB and MFC >worlds, and the experiences of the Java community to >create a clean and consistent framework.


    From COM and VB? Seems they learned they weren't very good.

    >Where we have raging debates about BMP ~and~ CMP Entity >Beans, JDO, various OR mapping tools and a cloud of open >source projects, the MS world has one elegant solution >(and if you don't like the use of the word ~elegant~ try >ADO.Net and tell me it isn't kind-of cool). And similarly >with UI, particularly on the server-side, the Java-world >has a disparate collection of technologies.

    ADO.Net is ok. With Java we have choice. I would rather have multiple wrenches as opposed to one shiny one. I like tools like Hiberate much more than ADO.Net. I don't like tying my domain objects to pesistance schemes (EJB's, JDO, JDBC, etc.) Of course in .Net there is no choice so I guess there is no need to separate.
  12. I got asked an interesting question, that I thought I
    should respond to

    ----------------------------------------------------
    Reading the paper, it seems that we should keep data and code apart. Just like you can with a non oo language and a database/file/constants/global variables.

    Is that right? Isn't OO about bringing data and functionality together (encapsulation, polyphormism....)?

    Also java already has coding styles and interfaces to make components (beans) using events and properties a reality. No need to add additional keywords.

    Did I miss the point?

    ----------------------------------------------------

    Component-Oriented programming makes the distiction between module behaviour and type behaviour. Module behaviour includes actions like finding and saving the types (e.g. EJB Home patterns), whilst type behaviour includes actions like calculating triangulation and validation of string lengths.

    On this last point of validation. It may be required to pass a type to another department for validation (e.g. for credit checking - strictly speaking verification ), in which case the credit validation would then be supplied by a credit validation service.

    From an OO perspective it may have been tempting to munge data validation with credit validation as 'validation' was a common 'behaviour'. From a component-oriented perspective the two are different things.

    I hope this gives an example how following component- oriented software design leads to a cleaner architecture.



  13. Seems to be suggesting that C# will do to Java what Java did to C++.

    However (whilst I do fully buy the C.O.P. bit) I think that argument (or rather inference) may be too simplistic; yes C++, C# and Java have come from corporate research, however C# is different in that it binds the developer to a platform, and therefore it is not necessarily true that it will attract over programmers, regardless of whether it is a small step forward.

    Also it is the mistake of developers not to seperate data from architecture in general Java programming, the idea of implementing these modifiers, type and module
    "
    public type class Invoice
    .....
    public module class InvoiceSession
    .....
    "

    doesn't make sense to me, since the only benefits of these restrictions are convenience (not declaring something serializable yourself etc.) There is nothing inherant in Java that prevents developers programming with seperation of data from architecture - its unfortunately arisen from poor training... (not being a snob (ok, maybe a bit) but I am sure VB developers will make their own hideous errors as they get to grips with C#!)

    At the end of the day we have to go with the flow, and the flow isn't always rational or well reasoned... but I for one am not going to be a bitter old Java programmer when the successor does come some day, however I think zealously looking to slur Java in favour of an immature rival is a mistake - which is the impression I am getting from BadManagers et al.


  14. The article raises an interesting point for discussion but I'm not convinced it actually answers it. Components are more than language constructs (obviously) and it is perfectly possible to do components within Java right now. Would Module/type semantics make any difference? I don't think so, or at least the article didn't quite answer it for me.
    I agree with the observation that Java (and in fact other OO languages/punters) overload the term component when they really mean object. Components still have some aspects of objects (i.e. encapsulation) but emerge from specification not implementation, which doesn't have to be object-based, although experience leads me to assert that it's certainly easier using objects. The old mantra of loosly-coupled, highly-cohesive has never rung truer than it does for components.
    I like the inference of separating data from function from framework and have been practicing this for many years. One respondent asked (and I'm paraphrasing here slightly) "isn't data and function together - encapsulation - what objects are about". The answer is Yes it is. The problem though is that pure OO doesn't work in practice on anything but small, encapsulated, non-distributed applications. The dependencies it creates are too large. The answer is stated in the first sentence of this paragraph and within the article but the reasoning can be seen in the way data is viewed: different problem domains have different views of the same data - imagine sales, marketing, call centre views of a customer. Tying data to logic makes for very convoluted, dependent applications.

    Following on from this somewhat, I think component oriented software (is this a new phrase - what is wrong with component based development?) needs covering from two perspectives: technical and business. The former is well represented by separation of data/function/framework as supported and constrained (yes, constrained) by application architecture. This is what supports a component approach to applications. The latter is represented by seperation of form/flow/function at the business level. I.e. form (how it looks) is independent of flow (how it hangs together - business process) which in turn is independent of function (how it works). Incidentally, I believe both these perspectives have roots in the MVC pattern which is the most scaleable, widely applicable, useful pattern I have ever come across.

    Having said all this, I'll repeat that the article raises interesting points that are worthy of ongoing discussion.

    A connected, but unrelated, point about something said in the article is with reference to the use of implied accessors with visibility based on that of the data member. This is wrong. The data member should ALWAYS be private and should ALWAYS be accessed via getter and setter methods which have their own applicable visibility. It's perfectly reasonable to imagine a scenario where a member can only be set by the type (private setter) but accessed publicly (public getter).

    I totally agree with the remarks about API bloom and I find myself questioning why the different api's never quite hang together.

    One more (controversial?) observation, not criticism: are some of the problems being seen in developed oo/component software due to lack of good foundations in OO techniques? I have experience of interviewing Java programmers (and architects!!) who couldn't explain concepts of polymorphism, why one would use interfaces (rather than how), problems of inheritance etc. Unfortunately this is more common than not and I suspect arises from the basically procedural backgrounds of these people.


    Andrew
  15. "A connected, but unrelated, point about something said in the article is with reference to the use of implied accessors with visibility based on that of the data member. This is wrong. The data member should ALWAYS be private and should ALWAYS be accessed via getter and setter methods which have their own applicable visibility. It's perfectly reasonable to imagine a scenario where a member can only be set by the type (private setter) but accessed publicly (public getter). "

    I agree with you. I don't like MyObject.color = BLUE either. Even if it really is MyObject.setColor(BLUE) behind the scenes (I think this is how the .NET compilers do it). Even if it doesn't really break encapsulation it looks like it does to the untrained eye.
    And (minor point here) when looking at the doc the prpoerties are separated from the methods making it more diffucult to locate what you want to find.
  16. Don't separate data from behavior. Do proper OO design.

    Don't write separate validation code. Validate in your setters.

    Don't use a string when a custom data type (like SSN) is more appropriate.

    Don't depend on logging for debugging. Use a debugger.

    Don't go directly to the database. It prevents you from using your code as it was inteded.

    Don't separate data from behavior. Do proper OO design.

  17. Adam Young wrote:

    >>Don't separate data from behavior. Do proper OO design.

    I have to disagree with the first sentence, although I would rephrase the second as "Do appropriate OO design". Empirical evidence shows that for anything but simple, non-distributed applications, structuring data and behaviour together causes too many dependencies and a fragile code base making support and maintenance difficult. I can only speak from my own experience here, but architecturally the separation makes sense. Could we not also infer from the use of Session Beans and Entity Beans that this is a general principle of EJB? Maybe.

    >>Don't write separate validation code. Validate in your >>setters.
    Actually I would say that the validation must be done in appropriate places. For example, taking the form/flow/function simple layering model I mentioned earlier, it might be appropriate to check simple validation in the form layer (e.g. correct date, string lengths etc), cross-validation in the flow layer (if varx is true, then vary must not be blank) and completeness validation in the function layer (e.g. are the correct parameters passed, do references exist within the persistence mechanism etc). Setters *may* be one place of doing this but in distributed systems, performance has to be a major consideration: do we want to move data from the browser, to webserver, to app server just to determine that a required field is blank?

    But lets not forget that the focus of this thread is about component software design and build which I believe needs a slightly different approach than that taken for OO applications. Whilst OO may be the implementation technology of choice, and for Java that is obviously the case, we need to understand the drivers behind doing components in the first place. There are both technical and business drivers which tend to be extensions of flexibility, integration, cost and speed to market. Component design is different to objects because we want to specifically control the cross-dependencies (i.e. low coupling) whilst maintaining integrity and function (i.e. high-cohesiveness). Whilst we may never actually reach the goal of plug-n-play software components, its worth striving part of the way.

    Still the devil is in the detail, and its early days yet but the theory is beginning to coalesce into acceptable practice. The debates and choices around CMP, BMP or session bean is an indication of this based on actually real-life experience. Alternative component architectures, such as .net, will only help us 'get there' sooner by building on the observations gained from Sun and J2EE.

    regards,

    Andrew
  18. but in distributed systems, performance has to be a major >consideration: do we want to move data from the browser, >to webserver, to app server just to determine that a >required field is blank?


    And this is one of the reasons HTML interfaces for business apps are bad. The reason you give for not having validation in the setter is really the reason we shouldn't be using HTML for interfaces. Another reason the are bad is because the validation can be bypassed by someone directly using the URL. Since we now can develop distributed apps that don't require browsers (in Java and .Net) they can and really should go away.

    I wouldn't say the validation should go in the setter but it has to go in the domain object.

    What happens if your app has an HTML frontend, a standard GUI, a batch job 'front end' (MQ, Job Scheduler, etc.), web services, handhelds, and voice or any combination? Where is the validation placed? All of these, EXCEPT for HMTL, will work if the domain object contains the validation.

  19. <quote>
    The data member should ALWAYS be private and should ALWAYS be accessed via getter and setter methods which have their own applicable visibility
    </quote>
    I think depending on the context it is perfectly acceptable to have public attributes.

  20. | I think depending on the context it is perfectly
    | acceptable to have public attributes.

    This may be, but an example or rule of thumb would have been helpful. There are several reasons to note make data members available directly.

    1) Ensure data members are only set to sane values (via validation in the setter)

    2) Enable object to react to the setting of a value (i.e. change other internal values and or call other interested methods, watchers).

    Other than simplicity of syntax, I can't see the value in making changeable data members public.
  21. This is where C# is nice

    foo.name = "Dion Almaer"

    could just be setting the name, until i need to make
    it do something else.

    I also think it reads nicer.

    However, its not really a big deal is it? I wouldn't change what language I used based on this ;)
  22. foo.name = "Dion Almaer"


    >could just be setting the name, until i need to make
    >it do something else.

    Fields are handled differently to method calls. In other words, you can't start out with this:

    public string Name;

    and change it to this:

    public Name {
        get {return _name;}
        set {_name = value;}
    }

    without recompiling client code.

    Jim

  23. >> foo.name = "Dion Almaer"
    >>
    >> could just be setting the name, until i need to make
    >> it do something else.

    I think my primary discomfort with c#'s properties can be illustrated by what you just mentioned - emphasising the word *could*. It indicates an uncertainty in what the code is actually doing..

    In C++, one of the pains that you were constantly guessing (or having to check) what was actually happenning when you read some code. If you saw an assignment a = b, it *could* mean the value of 'b' has been assigned to 'a'. BUT, you had to go check to see whether '=' had been over-ridden (and what the copy constructor did) ... in order to really know. It was usually a (unpleasant) surprise to step through some innocuous code in the debugger and discover what was actually executing.

    Fundamentally, I think it is important *for a language* to be able to read some code and very quickly understand what is going on. While a touch more verbose - it makes it easier to understand and, therefore, easier to maintain. If you always have to start checking in a number of places to see what is actually happenning, then the *language* loses readability and maintainability.

  24. I think my primary discomfort with c#'s properties can be >illustrated by what you just mentioned - emphasising the >word *could*. It indicates an uncertainty in what the code >is actually doing..


    Would seeing

    setName("foo");

    tell you anything more about an object's behaviour than seeing

    Name = "Foo";

    ?

    Maybe setName() deletes everything on your hard drive? Sure, it's possible that Name might be a field, but so what? Either way you're changing the state of some object, and you can never tell what consequences that may have just by looking at its interface.

    Horses for courses, eh? :-)

    Jim
  25. <quote>
    I think depending on the context it is perfectly acceptable to have public attributes.
    </quote>

    Would you mind giving some examples? (and then I will try to explain to you why it's a bad idea :-)).

    I take it we are not talking about public static final attributes, but attributes that should only be seen by the class.

    --
    Cedric
  26. The SWT designers seem to not have a problem with public fields:

    http://www.eclipse.org/articles/Article-Understanding Layouts/Understanding Layouts.htm

    SWT layouts (org.eclipse.swt.layout.RowLayout, for example) make heavy use of public fields, as seen in the code below:

        RowLayout rowLayout = new RowLayout();
        rowLayout.wrap = false;
        rowLayout.pack = false;
        rowLayout.justify = true;
        rowLayout.marginLeft = 5;
        rowLayout.marginTop = 5;
        rowLayout.marginRight = 5;
        rowLayout.marginBottom = 5;
        rowLayout.spacing = 0;
        shell.setLayout(rowLayout);

    The only serious problem I see with the above is that it doesn't comply with Java Beans conventions, in that the public fields would not be exposed as properties. That would (as far as I know) prevent an IDE from dynamically discovering the properties in the layout objects.
  27. The only serious problem I see with the above is that it >doesn't comply with Java Beans conventions, in that the >public fields would not be exposed as properties. That >would (as far as I know) prevent an IDE from dynamically >discovering the properties in the layout objects.


    If the IDE is only looking for setters and getters then this is an issue. Otherwise any method/field/property/constructor, regardless of access level, can be found.

    Well, some SWT visual editors should be coming out soon. We'll see then what impact this is.


  28. Would you mind giving some examples? (and then I will try >>to explain to you why it's a bad idea :-)).


    If you have Class1 that has fields of type Class11, Class12, Class13. Class12 has fields of type Class121, Class122. Class1 with all its constituent fields has to be mapped to one table in the database (don't ask why!) You could write a class FlatClass that has all the fields in all the previous classes. In my case this amounted to 65 fields. I don't need to check the values set to FlatClass' fields. FlatClass will be sent to a DAO where it undergoes minor changes before persisted to the database. Now Tell me why should I write 65 gets and 65 sets ?

  29. Sam,

    I would argue that designing your data model around how it has to be persisted is a poor choice. I'm not sure why an object with nested objects would have to be stored in one table [you told us not to ask why :-)]. Even so, I don't know why this would impact data encapsulation. And what if the constraints around having to persist the object(s) change - you are stuck with a flat object. Also, Class11, Class12 and Class13 are now 100% coupled with the parent class.

    One last thing - direct access to field ties you to the implementation. For example, say you originally have a field called "price" and you access it directly instead of using "getPrice". Later, you decide to derive the price dynamically and you want to get rid of the price field. Oops, can't do that - the field is accessed directly by code you no longer control. Direct access is a bad idea.

    Assuming that because you can access fields without any problems presently means that you will never have problems will get you into trouble. Requirements change. Code changes. Keep you code malleable.
  30. <quote>
    If you have Class1 that has fields of type Class11, Class12, Class13. Class12 has fields of type Class121, Class122. Class1 with all its constituent fields has to be mapped to one table in the database (don't ask why!) You could write a class FlatClass that has all the fields in all the previous classes. In my case this amounted to 65 fields. I don't need to check the values set to FlatClass' fields. FlatClass will be sent to a DAO where it undergoes minor changes before persisted to the database. Now Tell me why should I write 65 gets and 65 sets ?
    </quote>

    First of all, you need to clarify what exactly bothers you about that:

    1) The fact that you have to write them yourself
    2) The fact that they are (seemingly useless) wrappers around fields

    If 1), it's a matter of using the right tool. Use a macro, an IDE, whatever, but don't let a simple logistic problem like this one impact your design.

    If 2), just because you don't see the point right now doesn't mean it won't come in handy in the future.

    For example: what if you want to receive notification each time a field is set? If you have accessors, it's easy to add a firePropertyChange() in the setters. If you don't and some of your users are already accessing the fields directly, you are stuck.

    There are a lot of other reasons, but I think you get the idea.

    --
    Cedric


  31. The answer is stated in the first sentence of this >paragraph and within the article but the reasoning can be >seen in the way data is viewed: different problem domains >have different views of the same data - imagine sales, >marketing, call centre views of a customer. Tying data to >logic makes for very convoluted, dependent applications.


    It does if you treat it as data as opposed to attributes of objects. The question is then are they really are the same objects? And if they are, is this really just a security issue? If not, why are their views different? If the views do need to be different this can be solved with delegation.

    99.9% pure OO (some will argue Java is not pure OO) can be accomplished in a distributed system using the right techniques and technologies.

    Check out this book(pdf) on Expresive Systems - http://www.nakedobjects.org/downloads/expressive.pdf
    Not everyone can create expressive systems but it is a good concept and will help create good not expressive systems.
  32. If he wants to send messages instead of calling methods, he should use rmi or something similar.

    It seems to me that he does not know how to implement a proper MVC pattern using EJB..

    About AspectJ: yes, it would be nice to be able to set requirements using regex or whatever, you should for now just check arguments etc, and develop consistent.