Object Orientated question

Hi, I am trying to create a program which creates multiple instances of a class in a JPanel which each hold different variable values which can be altered by the user. I have created the Object class and the JPanel where the instances are created but i now need to make it so each instance of the class has a incrementing ID so I will be able to save the variable values of each instance including the x and y coords in the JPanel. This info then needs to be saved inside another class instance on a higher level. I am unsure of which method to use to be able to do this, could you help?

Well you would have to write the proper methods for deleting and adding notes.
As far as sending the notes to the Song from the network object, why even do that? Whenever you're dealing with a song, use a Song object to save your notes in order. A Network can contain multiple songs, or whatever, and a Song can contain multiple notes.
Check out the functionality of ArrayList: http://java.sun.com/javase/6/docs/api/java/util/ArrayList.html
If I were you, I'd get a single Song object working first before you worry about anything else. Throw in some dummy notes, doesn't matter if they sound nice, just to see it work. You don't even have to display them, just print out their values. When you finish that, then worry about displaying and working with them in a GUI.

Similar Messages

  • Object oriented question

    I am sure my n00bieness is going to shine here but I have a pressing question.
    I have two classes that do a similar activity they attach some elements to an xml document and then call a web service.
    Object A uses in its method signature different object parameters then Object B does.
    For example -
    Object A{
      public ProprietaryObject doMagic(ProprietaryObject po){
        //do stuff
    Object B{
      public DiffProprietaryObject doMagic(DiffProprietaryObject po){
        //do stuff
    }There is more than one method that is similar between the two objects but this is just to get the point across.
    Anyway, Instead of creating two separate objects that do "almost" the same thing (on different object types) how can I create an elegant solution to this?
    The problem I run into is that if I create a common interface for these two object to implement the object use different proprietary objects to do their work.
    I find that I keep using the instanceof operator everywehre to determine the object type.
    Hope this is not explained to horribly...
    Any help is appreciated!

    I'd create an Interface which defines a common access method for the-operations-you-require from both proprietory classes, then implement that interface in a couple of "boundary" classes which "wrap" the proprietory classes...
    If possible, extend the disparate proprietory classes, and delegate to the appropriate methods of the "real" classes.
    If the propritory classes are final then you have to write a ship load more "boilerplate" code... every single fraggin method has to pass the buck to the appropriate method of the private instance of the "wrapped" class, and return the result... which isn't usually too bad once you roll up your sleeves and get into it.
    From memory (mine is poor) this is the essence of the [Adapter pattern|http://en.wikipedia.org/wiki/Adapter_pattern].
    Like a said, there may be quit a bit of work involved, but the advantages usually outweigh the costs... You can "refer to" the disparate proprietory classes seemlessly throughout the rest of your system... if ProprietoryClassA changes (in the next release) you can (hopefully) adapt your adapter to those changes, without having to modify all your consumer code... because it still exposes the same interface... which is the motivation for any boundary class ("Trust no one";-)
    Cheers. Keith.
    Edited by: corlettk on 8/08/2008 06:28 - Better.

  • Declaration Error for Object orient Programming

    Hi All,
    can any tell me how to export Select-options .This is an object oriented question
    include ztest.
    select-options   : s_werks for marc-werks obligatory,
                       s_matnr for mara-matnr obligatory.
    data : O_object type ref to lcl_test.
    start-of-selection.
    CREATE OBJECT O_object EXPORTING IM_S_WERKS[] IN S_WERKS[]
                                     IM_S_LGORT[] in s_matnr[].
    Above statment is the problem 
    This is my include ztest.
    CLASS lcl_test DEFINITION.
    METHODS constructor IMPORTING IMWERKS[]   TYPE MARC-WERKS
                                   imLGORT[]   TYPE MARD-LGORT.
    Above statment is the problem
    endclass.
    Can anyone tell me how to declare
    Thanks
    Adi

    Hi Rich,
    This is what i have
    start-of-selection.
    CREATE OBJECT O_IMARD EXPORTING IM_WERKS = S_WERKS[].
    CLASS lcl_par DEFINITION.
    public section.
    TYPES: t_werks TYPE RANGE OF werks.
    DATA: r_werks TYPE t_werks.
    *types : begin of iwerks ,
    *SIGN(2) type c,
    *OPTION(2) type c,
    *low(4) type c,
    *high(4) type c,
    *end of iwerks.
    METHODS: constructor IMPORTING im_werks TYPE t_werks.
    endclass.
    CLASS lcl_par implementation.
    METHOD constructor.
    r_werks = im_werks.
    endmethod.
    endclass.
    My PROGRAM THROWS AN ERROR SAYINGS
    S_WERKS IS NOT COMPATABILE WITH IM_WERKS
    Let me know whats the issue in here
    Thanks
    Adi

  • Expose Object Oriented Service code as Web Services?

    Hello All,
    I would appreciate for your insight on this matter!
    Web Services are basically RPC (Procedure Oriented) over Soap. Each service invocation by a client results a procedure execution on the server side (In many case, a service class may need to be instantiated before the procedure can be called).
    Suppose I have developed server-side logics in Object Oriented manners. How can I expose the OO server logics as Web Services? Does JDeveloper handle OO services any different from PO (procedure-oriented) services as far as the generated wrapper code/interface and WSDL?
    Specifically, I have the following example in mind. Assume we are able to successfully expose an OO services. A client calls one of the OO service (let's say service1 in portType1) the 1st time, and establish some transit state (not committing into DB), the same client subsequently calls another service (service2) of the same server portType1. How would the server retrieve the transit state established earlier by service1 while executing service2? (note, this situation would not be resulted in a procedure-oriented case. since each RPC call is independent from the others)
    I realize that "stateful" deployment may be of an option. However, stateful seems relying on client cooperation (e.g., via cookies) to establish context across multiple invocations. This may or may not be possible given an arbitrary client parties write its client code based on a WSDL.
    Another option I can think about is for Jdeveloper to generated different code for PO services vs. OO services. However, it seems not the case in current Jdeveloper.
    Thank you so much!
    jason

    Web services in general have two styles of invocation: RPC style and Doc style. RPC maps as you say directly to methods on Java class (or if a DB PL/SQL package to procedures and functions).
    The alternative, DOC, generally (though not all the time) maps to a message oriented interface. Often DOC style Web services map to messaging infrastructure such as Java Message Service Queues and Topics.
    That said RPC works well with EJB's, the component model for J2EE.
    Often what folks will do is build a service layer that is very coarse grained when exposing backend infrastructure as Web services. This abstraction typically hides a more OO underpinning (or quite often hides a very procedural backend too).
    The bottom line is the Web services do not force an OO paradigm but nor do they hinder you in any way from adopting an OO paradigm.
    In terms of JDeveloper currently it supports RPC and supports DOC only with some tweaking. On the server side, the Oracle9iAS infrastructure supports both DOC and RPC.
    Hope this is a start to answering what I think is a hard question to answer!
    Mike.

  • Object Oriented Patterns and Visio

    Visio question:
    Does anyone know if there are established shapes for each (or any) of the object oriented patterns? If not, is anyone working on that or interested in that?
    Since they all have names (Momento, Proxy, Iterator, Mediator, Observer, etc.) it seems like they ought to each have their own shape. Since Object Oriented is all about communication of intent, each pattern having its own recognizable shape would go a long way toward a more meaningful communication through diagram. Also, if they each had their own shape, then the super-patterns (based on commonly grouped patterns and interactions) could also be easily represented.
    Blaine

    I'm kind of making an assumption here and if it's in error then feel free to disregard the rest of this post.
    Assumption that you're thinking terms of shapes for representing in UML the various patterns. Everything you need is right there in front of you already regardless of whether you use Visio, Rational, Poseidon or some other UML tool.
    Patterns are not individual constructs. One does not make a Mediator class. One makes a Java class that is an implementation of the Mediator pattern. As such you would see in the static class diagram the same grouping of classes for an X Mediator as you would for Y Mediator. That is the image you're looking for. It's not a single widget that you drag onto the screen, it's in the pattern itself.
    If, however, you're talking about something like a graphical representation to give to managers that says "Here be Momento patterns", then I would postulate that you're trying to communicate information that they don't need nor should they concern themselves with. Patterns are an implementation issue. They deal with, "How" we will solve a problem, not what problem will we solve. Mangaers, IMNSHO, need only concern themselves with what problems we will solve, not how they will be solved.
    Just my 2 krupplenicks on the subject, your milage may of course vary.
    PS.

  • Trying to understand the basic concept of object oriented programming.

    I am trying to understand the basic concept of object oriented programming.
    Object - a region of storage that define is defined by both state/behavior.
    ( An object is the actual thing that behavior affects.)
    State - Represented by a set of variables and the values they contain.
    (Is the location or movement or action that is the goal that the behavior is trying to accomplish.)
    Variables- (What does this mean?)
    Value - (What does this mean?)
    Behavior - Represented by a set of methods and the logic they implement.
    ( A set of methods that is built up to tell's the how object to change it's state. )
    Methods - A procedure that is executed when an object receives a message.
    ( A very basic comand.For example the method tells the object to move up, another method tells the method to go left. Thus making the object move up/left that combination is the behavior.)
    Class - A template from which the objects are created.
    ( I am very confused on what classes are.)
    - The definitions of the words I obtained from the "Osborne Teach Yourself Java". The () statements are how I interperate the Mechanisms (I do not know if Thats what you call them.) interact with each other. I understand my interpretation may be horribly wrong. I will incredibly appreciate all the support I may get from you.
    Thank you

    Object oriented programming is a replacement for the older idea of procedural programming (you can research procedural programming in google). As I understand it, in procedural programming, you have a step by step set of function calls to accomplish some task. Each function receives a data structure, manipulates it, and passes it to the next function. The problem with this is that each function preforms some action for the overall task and can't easily be reused by some other task. Its also harder to read the flow of what is happening with raw data structures flying all over the place.
    In object oriented programming, an object calls a function of another object and receives back, not a data structure, but another object. Objects contain a data structure that can only be accessed by its functions. An object is not so much a sub component of a bigger task, as it is a service that any other task can use for any purpose. Also, when you pass an object to the caller, the caller can ask questions about the data structure via its functions. The developer doesnt have to know what the previous function did to the data by reading up on any documentation, or having to reverse engineer the code.
    I suggest the best way of learning this is to code something like a library object.
    A library object contains a collection of book objects
    A book object contains a collection of chapter objects
    A chapter object contains a collection of paragraph objects
    A paragraph object contains a collection of sentence objects
    A sentence object contains a collection of word objects.
    Add functions to each object to provide a service
    Example: A library object should have a:
    public void addBook(Book book)
    public Book getBook(String title)
    public boolean isBookInLibrary(String title)
    The key is to add functions to provide a service to anyone who uses your object(s)
    For example, what functions (service) should a paragraph object provide?
    It shouldn't provide a function that tells how many words there are in a sentence. That function belongs to a sentence object.
    Lets say you want to add a new chapter to a book. The task is easy to read
    if you write your objects well:
    Sentence sentence1=new Sentence("It was a dark and stormy night");
    Sentence sentence2=new Sentence("Suddenly, a shot ran out");
    Paragraph paragraph=new Paragraph();
    paragraph.addSentence(sentence1);
    paragraph.addSentence(sentence2);
    Paragraphs paragraphs=new Paragraphs();
    paragraphs.addParagraph(paragraph);
    Library library= new Library();
    library.getBook("My Novel").addChapter("Chapter 1",paragraphs).
    Now, lets say you want to have a word count for the entire book.
    The book should ask each chapter how many words it contains.
    Each chapter should ask its paragraphs, each paragraph should ask
    its sentences. The total of words should ripple up and be tallied at each
    stage until it reaches the book. The book can then report the total.
    Only the sentence object actually counts words. The other objects just tallies the counts.
    Now, where would you assign a librarian? What object(s) and functions would you provide?
    If written well, the project is easily extensible.

  • Object oriented programming in LabVIEW

    Please send this message to everybody who has an opinion about this.
    Please try to keep it short, but if you can't control yourselves, let
    it all out!
    I would like to have your opinions about the nature of Labview and it's
    ability to support object oriented programming.
    I have a couple of questions to fire the discussion.
    1- Do you think that LV was built to support OO Programming?
    2- Is OO the only way we have to support large applications, or is it
    feasible to support it with a good dataflow architecture including all
    the flowcharts and all the data definitions?
    3- Is LV going to stay "dataflow" or is it going to become OO?
    4- What would be the great benefits of turning LV to OO that we don't
    already have w
    ith the dataflow approach?
    5- My opinion is that trying to implement OO in LabVIEW, is like trying
    to
    Thank you all for your time.
    Sent via Deja.com
    http://www.deja.com/

    > 1- Do you think that LV was built to support OO Programming?
    LV was initially designed in 1983. OOP existed at that point,
    but LV wasn't designed to be OO. It was designed to allow
    engineers and researchers a simple language appropriate
    for controlling their research labs from a computer.
    > 2- Is OO the only way we have to support large applications, or is it
    > feasible to support it with a good dataflow architecture including all
    > the flowcharts and all the data definitions?
    OO lends itself to large projects because it provides
    abstraction, encapsulation, and organizes code into
    modules that can more easily be implemented independent
    of one another since they can be specified in finer
    detail. Also, the compilers help to enforce the
    specifications providing they can be encoded in the
    interface between objects.
    These OO principles were already a part of big projects
    long before there were OO languages. It was just that
    the language didn't necessarily have features which
    supported it. Similarly, they can be a part of big
    projects today despite the language being used.
    LV 2 style globals, which as the name suggests were
    in use long ago, encapsulate data with an interface.
    They disallow arbitrary access to the data and can be
    used to enforce correct access. With other functions
    layered on top, you get a nice interface to stored data.
    Functions and structs/clusters abstract away details.
    Building a subVI that does an FFT means that for 99%
    of the uses, you don't need any more information except
    that this block performs an abstract mathematical function,
    an FFT. The implementation can be completely changed
    to speed it up or make it more accurate and your code
    isn't affected. Its abstract definition still holds, so
    your code still works.
    There are other things that OO languages bring to the
    table that LV, and GOOP don't yet offer. In my opinion,
    a few more OO features can be added to LV to allow for
    even larger projects in the future provided they are used
    well.
    Earlier posts pointed out that C++ doesn't guarantee that
    a project will succeed. OO features are just another tool,
    and the tool can be misused leading to a failed project.
    This is true to LV, C, C++, and all other engineering tools.
    The key is using the tools at hand to best solve the
    problems we face. Not glorifying or blaming the tools for
    the state of the project.
    > 3- Is LV going to stay "dataflow" or is it going to become OO?
    LV is dataflow to the core. The definition of what data
    is flowing may be expanded, but it will still be data
    flowing down wires from one node to another that accounts
    for how the program executes.
    One of the limitations of the current GOOP is that all
    objects are dealt with by a reference. By adding
    language features, objects could be made to flow down
    the wire, just like strings and arrays, meaning that
    branching a wire doesn't lead to side-effects,
    and there is no need to dispose objects.
    > 4- What would be the great benefits of turning LV to OO that we don't
    > already have with the dataflow approach?
    Remember when LV didn't have typedefs? It was easy for
    a cluster datatype to change once a project was underway.
    That usually led to lots of edits on other panels to get
    them back in synch. Without the unbundle by name, you
    then went through the diagrams fixing all of the bundlers
    and unbundlers to have the right number of terminals.
    Changing the order of the cluster was even worse since
    the diagrams may not bread, they might just access the
    wrong field instead.
    In many respects, an object is just another step along the
    same path. An object is a typedef that can have code
    associated with it for access -- maybe like Array and
    Cluster Tools. Some of the typedef contents might be
    publicly accessable, like now, while other elements are
    hidden, only available to the implementation of the
    typedef. That would force the user to use your functions
    to manipulate things rather than hacking away at the
    typedef contents. As an example, a LV string is really
    just a cluster of size and characters. Since the diagram
    can only modify the string using the string functions, you
    never get the size and characters out of synch. That is
    until you take it into LV generated code, a DLL or CIN
    where you have access to the inner fields.
    A related problem is that current typedefs are transparent
    to built-in LV functions. If your typedef is just some
    numbers, LV will be happy to perform arithmetic on your
    typedef. Maybe this is what you want, but if this doesn't
    make sense on your typedef, then your left with adding a
    Boolean or a string so that the arithmetic isn't allowed.
    Ideally, you would be able to state that = makes sense, >
    and < don't, + and - only operates on the first numeric, and
    * is something that you implement yourself. There would be
    some safeguards so that the user of your typedef, which
    includes you, wouldn't accidentally mangle the typedef
    contents.
    These may not seem like much at first, but they allow for
    much more abstraction and better encapsulation. Finally,
    there is a technique called inheritance that allows for
    similar objects to be acted on by common code in one
    location, and by specific code in another location depending
    on which type of object is actually there at runtime.
    This of usually done today by switching out on some inner
    tag and dealing with each type in its own diagram. This
    works fine until projects get large and teams get large.
    Inheritance is a different way of implementing the exact
    same thing that usually works much better for bigger teams
    and bigger projects.
    > 5- My opinion is that trying to implement OO in LabVIEW, is like trying
    > to
    Is this a fill-in-the blank question? It is difficult today
    because the LV language doesn't yet support OO very well.
    Early C++ was implemented on top of C using just a bunch
    of macros and the preprocessor to mangle the C++ back into
    C so that it could be compiled and run. Debugging was
    done on practically unreadable text that vaguely resembled
    your original code. By comparison, GOOP actually looks
    pretty good. It is written entirely on top of the current
    LV language and makes clever use of things like datalog
    refnums to make strict types.
    Over time I think GOOP will mature, and like typedefs,
    some users will come to rely on it in a big way.
    Other users will hopefully not even notice that anything
    changed. If their project grows in complexity and they
    need another tool to manage things, it will be just
    another feature that helps them to get useful things done.
    Greg McKaskle

  • How do YOU name classes? (object oriented programming)

    I am in the process of learning advanced object oriented design, and I am trying to use it in my personal programming project. I'm having a hard time implementing all of the classes I want for it because I can't think of what to call them.
    So, my question is, in object oriented design, how do you name the implementations and abstractions that you make?
    In other words, "implementations" can be thought of as "classes", and "abstractions" as "interfaces" in Java or "pure abstract classes" in C++. How do you name the classes and interfaces you make?
    For example, do you use prefixes or suffixes on your names, such as "I" for "interface" or "Impl" for "implementation"? Do you add "-able" to the end of the name of an abstraction, such as "Decoratable"? Can you always think of simple logical names for all of your classes, and it just has never been a problem for you?
    As an example of how the number of classes quickly grows, the Decorator Pattern will use at least five classes. I have no idea what I would name those in a programming project.

    drcouzelis wrote:
    Trent wrote:Theoretically speaking, you'll have multiple implementations of the Window interface, which will have their own unique names suggested by their respective purposes.  If not, then Window and its implementation should probably be merged into a single class.
    Thank you for bringing that up.
    How about this: The name of the implementation class will be HOW its implemented followed by the name of the interface.
    A "Window" interface would have implementations such as "AllegroWindow", "GTKWindow", or "HaikuWindow".
    In a video game, a "Character" interface would have implementations such as "GeneralCharacter", "ControllableCharacter", "PlayableCharacter", or "EnemyCharacter".
    Does that sound like a good idea?
    Indeed, classes are more specific than interfaces, subclasses are more specific as their superclasses... This should be reflected in their names, the name of a class that implements an interface should somehow make clear exactly what it is (e.g. what kind window). If you have a kind of window (for instance) that is really _just_ a window, nothing else, than the interface should become this class and the implementing classes should become subclasses.

  • Object Oriented vs Context Oriented Programming

    A few weeks ago, I submitted a Paradigm Shift: the WDP Model & the Power to Bind in which I tried to argue for a more object oriented approach to the structuring of WDP Components by using the javabean model as an abstraction layer for the WDP Context structure. My thinking on this matter has led me to another realization - an even more radical one at that, as it raises questions on a universally accepted feature of the Web Dynpro architecture:
    <b>Is it really wise for a WDP Component to expose its Context to the world?</b>
    Doesn't that go against the principle of encapsulation - one of the most important principles of object oriented theory? A component could and should be completely defined by the methods, properties and events it exposes to the outside world. Any client wishing to avail itself of the Component's services should be able to do so through this well defined interface - and all the rest should remain implementation details. That's how most component models I've worked with usually work.
    SAP has done a decent job of designing WDP Components that have the expressive power to expose methods, properties and events. Why isn't this sufficient ? Can anyone here explain to me what advantage one gains by exposing the internal workings of the Component (ie its Context) thereby breaking the fundamental OO principal of encapsulation ? Isn't this "feature" of Web Dynpro actually encouraging bad OO development practices? Anyone from SAP's Web Dynpro Design team would care to take a shot at this one? Do they read these forums?
    Romeo Guastaferri

    Hello Valery
    I don't quite agree with you when you say "Context is in fact grouped hierarchical properties of controller". I would tend to say it's more like grouped hierarchical properties of the UI Elements and the Model objects that are used by the Controllers and Views. It is a structure designed for sharing data between Views and Controllers of a Web Dynpro Component. And as such, is an implementation level construct that should remain encapsulated at the Component level. Where I draw the line is in the practice of sharing Contexts between Components.
    page 13 of <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/a048387a-0901-0010-13ac-87f9eb649381">The Structural Concepts of Web Dynpro Components</a> states that
    <blockquote>
    "...the Web Dynpro component is a reusable unit of code at the business process level, rather than the technical coding level."
    </blockquote>
    However, the Context is a technical Web Dynpro construct, not a business level concept. Why would you need to access the Context structure at the business level ? As a business client, I shouldn't be expected to master context manipulation api and have to navigate a structure to get at the information stored at the current lead selection. I should be able to easily query the component by invoking some
    component.getSelectedEntity()
    method. Let the component worry about navigating whatever internal representation it chooses to use (whether it be it Context API, JNDI, XML or whatever)... and just give me the information I need and ask for - in a format that makes sense to me, from a business perspective. I find this to be much more in tune with OO philosophy.
    I shouldn't have to (and shouldn't be allowed to) dig in for myself in the data structure to extract the bits of information that I need. And it's for this reason that I expressed my opinion that exposing the Context at the Component level is not only unnecessary (properties, methods and events are perfectly adequate to publicly characterize a Component) but actually encourages bad OO programming practices.

  • I want to learn more about OOABAP(Object Oriented ABAP)

    Hi All,
    Please could anybody help me in sending some of material or suggestion in learning(Exploring) the Object Oriented ABAP. Right now I am an ABAP/4 Developer.
    Please if anybody having any such material please send it to my mail-id i.e <u>[email protected]</u> or else please tell me the resources to learn the OOABAP please.
    Now I have to work on that project. Thanks in advance.
    By
    ASHOK
    If anything PDF format material please could you upload to my mail ID <u>[email protected]</u>
    Message was edited by: ashok vanga

    Hi ashok,
    check this link....
    http://www.intelligententerprise.com/channels/applications/feature/archive/heymann.jhtml?_requestid=304802
    http://www.henrikfrank.dk/abapuk.html
    http://sap.ittoolbox.com/documents/document.asp?i=982
    reward points for helpfull answers and close the thread if your question is solved.
    regards,
    venu.

  • FOR ALL ENTRIES in Object Oriented Context

    Dear all,
                is it possible to use FOR ALL ENTRIES for an internal table with out header line ? I Am using Objected Oriented Programming and I Am not able to create internal table with header line . Please provide your valuable inputs on this issue.
    Thanks In Advance.
    Sri

    Hello,
    Few questions:
    1. Did you do an F1 on FOR ALL ENTRIES(FAE)? Does it say FAE is allowed only for tables w. header line?
    2. Have you tried using FAE on an internal table w/o header line? Does it give an error?
    BR,
    Suhas

  • Help with object oriented concepts

    I am a senior highschool student and although I know Java syntax, I learned with Pascal and other procedural languages so I have a difficult time thinking in OOP concepts (which I will have to learn for college classes). So for practice I went to my college's website and found an assignment on the intro course to programming: [Here are the assignment instructions.|http://www.cs.gsu.edu/knguyen/teaching/2009/spring/csc2010/proj.pdf]
    My question is, how can I make my program illustrate more object oriented concepts?
    Links:
    ode-help.110mb.com/javaproject.java_

    Just a few comments (not necessarily about OO and in no particular order):
    It's probably not worth it to make constants for the letter A or the plus sign. Make constants for values people would not understand:
    // Ok
    public static final int ANSWER_TO_THE_UNIVERSE = 42;'
    // Probably overkill
    public static final int FORTY_TWO = 42;
    Good job on having DecimalFormat as a regular instance variable rather than static (since it is not thread-safe)
    Good job initializing your object in a consistent state (via the ctor). Now, make as many variables final as you can. Immutable objects are good:[www.javapractices.com/topic/TopicAction.do?Id=29]
    Not sure why you declared repeat() to return the boxed version of boolean, just use a primitive
    You have a run() method but are not implementing Runnable. Not that it is required, but usually when I see run(), I think of threading
    This is a matter of style, but you don't need to name the arguments in the ctor differently than the instance variables that get assigned. You can very easily say:
    // Note that it is final.  Make things immutable when you can.
    private final String bar;
    public Foo(final String bar) {
       // Note:  I don't need a different name here.  This is purely a matter of personal style.
       this.bar = bar;
    Consider a while loop in run() rather than a do-loop. What happens if you get no input the first time around?
    Java naming conventions dictate that classes start with a capital letter. Generally, an underscore is not used, camel-case is. So, your class should be JavaProject.
    Consider making an object for the arguments that are passed into input. Maybe call it GradeCategory, or whatever.
    That new object GradeCategory can have the output() method.
    For method names, also follow conventions using camel case. So get_double should be getDouble().
    Consider reworking such that you use an array or a collection of GradeCategory. You might want to then have an add method in your JavaProject. The add method should ensure the total weight of grades does not exceed 100%.
    You can rework the output method of JavaProject to iterate over your GradeCategory objects, calling their own output() methods. Perhaps it also first checks that the weight of all grades equals 100%.Just a few thoughts.
    - Saish

  • Can I develop a 100% Object Oriented DB with Oracle 10g?

    Hello!
    I need to know if I can develop a pure Object Oriented Data Base? because I have been looking for this information, and I just found Oracle's arquitecture is oriented to relational object model.
    Thanks!
    Edited by: 925803 on 05-abr-2012 10:39

    Dear "925803",
    1) You're asking this question in the Oracle Application Express discussion forum - not really related to generic Database questions. This Database forum may be more suited: General Database Discussions
    2) The Oracle database is not an object-oriented database.
    Joel

  • Is java 100% pure object oriented?

    I am very confuse is java 100% pure object oriented language.
    bcoz
    1)object oriented means everything should be in object but
    primitive data type is not object.
    2) java don't support multiple inheritances which is one of the oop 's
    concept

    I'd say that java is 100% java. No more, noless.
    I'm gonna say it's about 99.4738383% java. For
    no
    reason other than to confuse idiotsSomeone's always bumping their heads against
    some
    arbitrary theoretical purity when they aremissing
    what was, is and always has been most important:
    functionality.Functionality matters virtually nothing to thepeople
    that post these "questions". All that matters is
    being able to say the right thing in interviews so
    they can get a job and get carried through their
    career by people who actually know what they're
    doing. See it all the timeHehe, who carries you whilst you post here all day
    :P
    Ant builds, mostly :p

  • Object Oriented? Or Not?

    Perhaps the way I raised this question would be peculiar for you as I'm a newbie!
    I'm willing to use oracle object oriented programing for my applications, and some senior people(work in my organization) told me that Object oriented database concept is failed in the industry. As a reason they say that; even if Object oriented databases solved some problems people had with relational databases, still Object oriented databases are failed to facilitate most of the advantages of relational databases. It's somewhat chaotic for me, as I'm new to PL developments.
    They didn't mention any specific reason; but just told me that relational databases perform well and faster than object oriented databases, and for business logic, object oriented databases has some accuracy issues.
    But I'm not ready to accept that it will be useless to learn 'Oracle Object Oriented Programing' or 'Object Oriented Database Concept' would be failed.
    So I need to know,
    1. Will it be useless to learn & use 'OOP' techniques when learning PL/SQL programing?
    2. Is there any disadvantage of using 'OOP' with oracle? (If there is any, please let me know if you have time for that).
    Especially, (The most pleasing answer I would like to hear from you ;-) )
    3. If Object Oriented Databases concept is better and something that a "PL/SQL" developer must learn; please let me know that.
    Please provide me a link if you can, which would help me to learn why should we use 'OOP' with oracle (if Object oriented database is better than Relational database)

    Intruder wrote:
    So I need to know,
    1. Will it be useless to learn & use 'OOP' techniques when learning PL/SQL programing?No. OOP has very little do with relational database design. The two is not mutually exclusive and can co-exist easily.
    2. Is there any disadvantage of using 'OOP' with oracle? (If there is any, please let me know if you have time for that).That depends on how+ you use it. If OOP was truly horrible and bad, then why does Oracle spend money on the research and development on it for their RDBMS product?
    Especially, (The most pleasing answer I would like to hear from you ;-) )
    3. If Object Oriented Databases concept is better and something that a "PL/SQL" developer must learn; please let me know that.OOP is not Object Orientated Database. These are two very different concepts. OOP competes with procedural programming. Object Orientated Database design competes with Relational Database Design (and others of course).
    There are two primary issues with an Object Orientated Database design. Complexity. Performance.
    Do you for example store the subclasses of the same abstract class in the same physical object table? You can do that in Oracle.. but then the database need to resolve the class type at run-time.. every single time.. for every single object accessed... At what cost ito performance?
    How do you treat collection classes? A collection can be stored as a physical table. It can also be stored as an attribute (column) of an object (table) - in which case the physical implementation for that is a nested table. There are dire performance issues with nested tables when these are used and applied incorrectly.
    There are numerous such issues.
    Compare this with something as mature and robust as Relational Database Design. Easy to understand. Easy to use. And what the Oracle RDBMS product was specifically designed to support.
    Which one is "+better+" (especially in the Oracle RDBMS environment)? It should be obvious.
    I suggest that you read Codd's original paper on "+A Relation Model of Data for Large Shared Data Banks+", read "+The Third Manifesto+" from Chris Date, and papers from various other authors for insight.

Maybe you are looking for