This discussion is archived
1 2 Previous Next 21 Replies Latest reply: Mar 14, 2013 9:21 AM by jschellSomeoneStoleMyAlias RSS

in OOP - should there be two types of classes ?

syparth Newbie
Currently Being Moderated
I have always had a confusion in OOPs.
If we would have all the objects , then where these objects would be processed ?
There should be some processing class , whose method would process these all objects ,
like "main" method, there can be many processing classes , which will create objects if required and call their methods and do the process.
And these classes are different than the classes which are having objects.
These classes should not have , ideally , any global variable or attribute. These classes are the only processors.
If you agree then we should have two types of classes in OOPs java.

Edited by: syparth on Mar 13, 2013 8:26 AM
  • 1. Re: in OOP - should there be two types of classes ?
    PhHein Guru Moderator
    Currently Being Moderated
    So where do you put view classes, controller classes, process classes? The type you're writing about is purely defined by the methods defined in the classes. The consequence is, that there are loads of different 'class types' in your sense.

    Why shouldn't have a processor class owm attributes? This doesn't make sense, as you've often got attributes defining the context of an instance.
  • 2. Re: in OOP - should there be two types of classes ?
    syparth Newbie
    Currently Being Moderated
    Ok processor class can have attributes , that was just an exaggerated view,
    As we do use different classes , in some frameworks , like - Valuobject , Business Object , Controllers , DAOs , - why such patterns are not being adopted in OOPs .
    As the way OOP defines the "class" that is only "ValueObject" or "Business Object" or "Bean" as named in known frameworks.
    I think OOP should be changed or broaden now .
  • 3. Re: in OOP - should there be two types of classes ?
    EJP Guru
    Currently Being Moderated
    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.
  • 4. Re: in OOP - should there be two types of classes ?
    syparth Newbie
    Currently Being Moderated
    Ohh, You are saying "As we do have such classes, clearly they are being used. " ?? strange ..
    Ok , Can you please name me any OOP theory or OOP language theory where in such types of class are uttered even ? Do not name any Java Framework.
    Do not break the sentences if you want to read something , read the whole passage and try to understand.
    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.
  • 5. Re: in OOP - should there be two types of classes ?
    EJP Guru
    Currently Being Moderated
    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?

    You are just trying to conflate two things that are completely distinct.
  • 6. Re: in OOP - should there be two types of classes ?
    syparth Newbie
    Currently Being Moderated
    Sir , I am trying to put a note that , Java should accomodate such concepts so that it would be clear.
    "Class" keyword makes confusions. "ValueObject" , "Business Object" , "Bean" , "Controller" , "Processor" keywords would make the ideas of OOP clear ,
    OOP concepts are confined to the worldly objects because of "Class" , though the developers have infused their own concepts with "ValueObject" , "Business Object" , "Bean" , "Controller" , "Processor" for "Class" components.

    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 ? Can you say it is a bean or a processing area or a ValueObject or Data Transfer Object or a Controller.
    Commenting on this point I am trying to convey that , these patterns of classes should be adopted to the original Java language components.
  • 7. Re: in OOP - should there be two types of classes ?
    EJP Guru
    Currently Being Moderated
    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 clear
    There 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 objects
    OOP 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:

    - its name
    - its package
    - its annotation
    - its Javadoc

    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.
    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.
  • 8. Re: in OOP - should there be two types of classes ?
    syparth Newbie
    Currently Being Moderated
    Let me take an example and convey you , please do not tear the sentences , read the post as whole , and please do not get baffled looking at "capital letters " in keyword , please go through the concepts only .
    Take one example in programming patterns - "Singleton" pattern.
    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.
    If you want to check wheather the class is Singleton or normal you have to gone through many parts of the class - like you said in your last post - "you will look at lots of things of the class ".
    A normal class and a Singleton class , both are too much different concept wise .
    I am pointing to these concepts , that the "class" is too much generalized concept. It needs specialization concepts in OOP or OOP language.
  • 9. Re: in OOP - should there be two types of classes ?
    gimbal2 Guru
    Currently Being Moderated
    EJP wrote:
    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.
    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.
    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.

    But yeah which kind of classes you can create... it would be very sad indeed if a programming language would dictate that - unless the language itself can actually be extended by them, such as Enum and Annotation classes in the case of Java. But thats the limitation: it needs to be a benefit to the programming language and by extension its users. It must not be done to turn the language into a framework.
  • 10. Re: in OOP - should there be two types of classes ?
    syparth Newbie
    Currently Being Moderated
    Let me take an example and convey you , please do not tear the sentences , read the post as whole , and please do not get baffled looking at "capital letters " in keyword , please go through the concepts only .
    Take one example in programming patterns - "Singleton" pattern.
    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.
    If you want to check wheather the class is Singleton or normal you have to gone through many parts of the class - like you said in your last post - "you will look at lots of things of the class ".
    A normal class and a Singleton class , both are too much different concept wise .
    I am pointing to these concepts , that the "class" is too much generalized concept. It needs specialization concepts in OOP or OOP language.
  • 11. Re: in OOP - should there be two types of classes ?
    EJP Guru
    Currently Being Moderated
    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.
    If you want to check wheather the class is Singleton or normal you have to gone through many parts of the class - like you said in your last post - "you will look at lots of things of the class ".
    Not really. I look at the Javadoc.
    A normal class and a Singleton class , both are too much different concept wise.
    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?

    Again you are merely conflating theory with practice. If we were to add theory, or keywords, for every new application of the theory, we would rapidly end up with a milllion keywords, an unmaintainable and unusable language, and the immediate necessity to introduce a new one with less baggage, fewer preconceptions, and more expressive power. That in a nutshell is the history of programming languages since about 1941.

    If you have a concrete proposal corresponding to any of this waffle, let's have it so we can actually debate something real. Do you really want to add 'singleton', 'abstract factory', 'visitor', 'bridge', etc etc etc as ... what? Keywords in the Java language? Concepts in OOP? What's wrong exactly with the way things are now, where these things are expressed either in the class name itself or in its documentation? What happens when someone (God forbid) invents a new design pattern? What is it exactly that you are proposing here?
  • 12. Re: in OOP - should there be two types of classes ?
    syparth Newbie
    Currently Being Moderated
    Am not sure , why you want to limit the OOP language , with limited keywords and concepts.
    To make a note on a class weather it is a simple class or singleton class you would sit to read the whole javadoc ? or emphasize the programmer to write specifically "singleton" word in his rehtorical javadoc ? the programmer might use other terminology in javadoc instead of "singleton" word. Why you want to make such things so much messy ? Instead of allowing Java to introduce a keyword and concept "Singleton class " ?
    Just to save the alphabetical keyword parsing of Java language ?

    +"If we were to add theory, or keywords, for every new application of the theory, we would rapidly end up with a milllion keywords, an unmaintainable and unusable language, and the immediate necessity to introduce a new one with less baggage, fewer preconceptions, and more expressive power. That in a nutshell is the history of programming languages since about 1941."+

    This argument does not make a sense even for concepts which are highly adopted in the programming. You might not be aware of it or might be ignoriing it.


    No they aren't. They both exhibit class, object, encapsulation, behaviour, polymorphism.

    have you realized the singleton concept , apart from the visible similarity of class, object, encapsulation, behaviour, polymorphism ? singletons are limited to single objects , while many objects can be created from a normal class.
  • 13. Re: in OOP - should there be two types of classes ?
    Kayaman Guru
    Currently Being Moderated
    You're talking about singletons so much that one might think you just learned about it.
    A singleton class is easy to spot, unless the developer has intentionally attempted to hide it.

    Observe a typical singleton:
    /** This singleton contains bla bla bla */
    public class SystemInfo {
        private SystemInfo instance = new SystemInfo();
        private SystemInfo() {}
        public SystemInfo getInstance() {
            return instance;
        }
    }
    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.
    If I understood correctly, you would rather have it this way:
    /** This singleton contains bla bla bla */
    public singleton SystemInfo {
        // Omit boilerplate, trust that the singleton keyword generates this
    }
    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.

    Your arguments aren't good and you're obviously not very skilled in either OOP or Java.
  • 14. Re: in OOP - should there be two types of classes ?
    syparth Newbie
    Currently Being Moderated
    I request your goodself do not drag the discussion in different direction by assessing the skills of people . I am not sure your way of assessment , neither I am interested in your singleton code copied from somewhere.
    wisely read the whole post instead of the last one , then comment .
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points