text: As we do use different classes , in some frameworks , like - Valuobject , Business Object , Controllers , DAOs , - why such patterns are not being adopted in OOPs .A meaningless question. As we do have such classes, clearly they are being used.
  As the way OOP defines the "class" that is only "ValueObject" or "Business Object" or "Bean" as named in known frameworks.Also meaningless. Not even a sentence.
  I think OOP should be changed or broaden now .You're welcome to your opinion but you're not making much sense.
  Ohh, You are saying "As we do have such classes, clearly they are being used. " ?? strange ..Nothing strange about it.
  Ok , Can you please name me any OOP theory or OOP language theory where in such types of class are uttered even ?Of course not. That's OOP theory. It is about objects ,classes, inheritance, encapsulation, message-passing, polymorphism, etc. The class types you mention are strictly in the domain of practical application. Adding them into the theory just conflates theory and practice. It doesn't clarify either of them.
  I am talking about the OOP theory or OOP language theory. They have not classified the "classes" with various types. The classification is given by good frameworks and which really needs to be adopted by OOP theories or OOP language theories.Why? What part of OOP theory is broken by the existence of extra kinds of application classes?
  I am trying to put a note that , Java should accomodate such concepts so that it would be clear.So now your question is about Java, not OOP. You now want Java to accomodate the concepts. Not OOP in general. You've changed your tune completely in the space of one post.
  "Class" keyword makes confusions.There is no 'Class' keyword. There is a 'class' keyword. It 'creates confusions' such as ?
  "ValueObject" , "Business Object" , "Bean" , "Controller" , "Processor" keywords would make the ideas of OOP clearThere are no 'ideas' of OOP in these keywords. There are some ideas of Design Patterns, and no ideas of Java whatsoever.
  OOP concepts are confined to the worldly objectsOOP concepts aren't 'confined' to any 'worldly objects'. You aren't making sense.
  because of "Class"Keywords do not confine concepts. If you want to add more keywords to the Java language, you have basically zero chance, and you are posting in the wrong place: try the Java Community Process; but I can tell you now you will have no better luck than you are getting here.
  , though the developers have infused their own concepts with "ValueObject" , "Business Object" , "Bean" , "Controller" , "Processor" for "Class" components.Good for the developers. What does that have to do with OOP? or the Java language?
  In today's complex programs (written in a simple Java program , without using any frameworks like spring,struts) , looking at a "class" component what would you think of it ?I would think it's a class. Your mileage might vary. I would also look at:
  Can you say it is a bean or a processing area or a ValueObject or Data Transfer Object or a Controller.Yes, if I look at the aspects I mentioned above. I would certainly not expect to be able to do so via keywords in the language. What happens when someone invents a new design pattern and there isn't a keyword for it? Does history stop?
  Commenting on this point I am trying to convey that , these patterns of classes should be adopted to the original Java language components.No. You are saying the opposite, that the Java language components should be adapted to these patterns of classes. It isn't a coherent or defensible proposition.
  EJP wrote:Agreed. Of course agreed, a programming language should be logical and controlled, the situation sketched here is utter chaos. Would be nice for book sales though, you'd have to release updated versions very often indeed.
  I would not expect a Java keyword to be added for every arbitrary fashion in computer programming that came and went. I've seen too many of them.
  It is not the function of programming language design to record or express design intent. There is a good 60 years of experience to back this up. Clearly you have never done it.Not entirely agreed. One can reason that the basic design of the Java language actually forces some design intents on the programmers. For example explicitly not supporting multiple inheritance and unsigned types forces you to do things in very specific ways, such as applying interfacing. Heck: the fact that Java is object oriented already forces a very specific design intent: thou shalt write object oriented code! and I'm glad Java is designed the way it is; you can still do everything you need to do, with less risk of doing it horribly wrong.
  Take one example in programming patterns - "Singleton" pattern.I'm getting sick of this 'worldly objects' business. I don't know what it means. You are talking about OOP theory and/or the Java programming language, it's hard to tell which, neither or which contains any notion of 'worldly objects'. Please stick to the point.
  Why do we need Singleton pattern ? because we do not need any more object of a class. So such class defines something different than other classes which defines the worldly objects' concepts.Not really. I look at the Javadoc..No they aren't. They both exhibit class, object, encapsulation, behaviour, polymorphism.
  I am pointing to these concepts , that the "class" is too much generalized concept. It needs specialization concepts in OOP or OOP language.Why? Are we to understand that you want (a) keywords for every design pattern, or (b) changes to OOP theory to accomodate every new design pattern?
  Even if the javadoc doesn't mention it's a singleton, the lack of public constructors and the presence of getInstance() are tell-tale signs.Even if the javadoc doesn't mention it's a singleton, the lack of public constructors and the presence of getInstance() are tell-tale signs.
  /** This singleton contains bla bla bla */ public class SystemInfo { private SystemInfo instance = new SystemInfo(); private SystemInfo() {} public SystemInfo getInstance() { return instance; } }
  Now do the same for all the design patterns and suddenly you've got a 1000 more keywords and basically a framework created inside the Java language.Now do the same for all the design patterns and suddenly you've got a 1000 more keywords and basically a framework created inside the Java language.
  /** This singleton contains bla bla bla */ public singleton SystemInfo { // Omit boilerplate, trust that the singleton keyword generates this }