Object Oriented AS3 game programming - where do I start?

I’m a programmer familiar with object oriented
programming, with experience in C++, C# and the MS Visual Studio
development environment.
I’ve been tasked to create a web based game using Flash
CS4 and ActionScript3. I am new to Flash, ActionScript and game
programming. I have never used previous versions of Flash or
ActionScript.
The game will be a single player role playing game. The
player will have the ability to create an avatar.
The player will move the avatar from screen to screen based
on button clicks or drag and drop onto objects in the current
screen.
Players must register, and player information will be stored
in a database backend. Additonal data will be saved to the backend
database during game play.
The saved data will be based on player actions in various
screens, and in some cases data entered in a form on a screen.
For a first pass a stick figure avatar and screens containing
simple buttons and simple objects to drag the avatar to will be
sufficient. I would like to store data in a database tracking
date/time information, e.g. date/time each screen is
entered/exited.
Any links to articles, or better yet, sample code showing
these concepts would be greatly appreciated – Thanks

Start is relative term. It took me too long just to find out
how to "hello the world" so I'll save you that work.
In Flash (Note: I'm using CS3 but I doubt this part of the
menu has changed that much)
1) File -> New -> ActionScript File
2) Paste in the following:
package junkdir {
import flash.display.Sprite;
public class junktest extends Sprite {
public function junktest() {
trace("Hello world");
3) Save as some_folder/junkdir/junktest // obviously create
new folder 'junkdir' during this process
4) File -> New -> Flash File (Action Script 3.0)
5) In the properties field labeled 'document class' type in
junkdir.junktest // THIS WAS THE OBSCURE PART
If the properties field did not automatically open then
manually open with: Window -> Properties -> Properties
6) Save this file as 'junk' in some_folder
7) Control -> Test Movie
"Hello World" appears in the Output Window. (This also can be
opened manually)
Read whatever Adobe online docs gets you involved quickly, I
like the display objects just for a quick visual high. Most code
will cut and paste into this 'junk' framework.
I recommend two O'Reilly books: Actions Script 3.0 Quick
Reference Guide by Stiller, Shupe, deHaan & Richardson and
Essential ActionScript 3.0 by Collin Moock.
Hope this helps. Good luck.

Similar Messages

  • Never programmed a game before, Where do I start, GDI?

    Hey all
    I am an intermediate VB, C++, Java programmer, but I have never programmed a game. I dont want to do anything complicated yet like a 3D engine, but I did want to do a side scroller. Can someone point me in the right direction. Things I should read, websites, advise, etc....
    Thanks in advance
    Ruko Kahn

    The first thing to do is plan out how you want everything to look, then throw some test graphics together. Once you have the game planned/mapped out, the engine is the first thing to start. There are actually some good 3D engines out there to use (such as TegoSoft's), but for a 2D engine, you need to make the graphic area, sprite routine (double-buffering to make it smooth!), and a series of functions to make it easy to place sprites on the graphic area. If this is your first game, I'd start with something a little easier, say, a board game like Othello or Ataxx. That will give you the basics of placing pictures on screen and intercepting the key presses/mouse clicks without near the frustrations that starting out with an action sidescroller would :) Once you have that mastered, then move on :). Good luck to you! Once you have the game done, maybe you'd want to think about connecting it to the internet and making it multiplayer. We need more interplatform multiplayer games =)
    MagiTom

  • Object Oriented Blackjack game for class final...

    I'm trying to accomplish my final & this is what I have so far. The teacher has given permission to use outside resources, so I'm hoping you can help.
    This is what I have so far.....any suggestions?
    Thank you
    //Play one hand of Blackjack
    import java.util.Random;//program uses class Random
    public class Blackjack
         private String dealer;//Dealer who does not play
         private int player1;//Player one of three
         private int player2;//Player two of three
         private int player3;//Player three of three
         Random randomNumbers = new Random();//Random number genertor
              //enumeration with constants that represent game status
              private enum Status{ HIT, STAND, WIN, LOST }
              public void Blackjack( String Alice, int Emily, int Matt, int Mary )
                   //initializing variables in declaration
                   Alice = dealer;
                   Emily = player1;
                   Matt = player2;
                   Mary = player3;
                   int nextCard;
                   int totalHand;
                   Status gameStatus;
                   int sumOfCards = dealCard();
                   int Blackjack = 21;
                   int hit;
              public int dealCard()//deal cards, calculate sum and display results
                   //Player1 is dealt 2 cards
                   int card1 = 1 + randomNumbers.nextInt( 10 );
                   int card2 = 1 + randomNumbers.nextInt( 10 );
                   int sum = card1 + card2;
                   System.out.printf( "Emily is dealt %d, %d\nHer hand is: %d\n",
                   card1, card2, sum );
                   //Player2 is dealt 2 cards
                   card1 = 1 + randomNumbers.nextInt( 10 );
                   card2 = 1 + randomNumbers.nextInt( 10 );
                   sum = card1 + card2;
                   System.out.printf( "Matt is dealt %d, %d\nHis hand is: %d\n",
                   card1, card2, sum );
                   //Player3 is dealt 2 cards
                   card1 = 1 + randomNumbers.nextInt( 10 );
                   card2 = 1 + randomNumbers.nextInt( 10 );
                   sum = card1 + card2;
                   System.out.printf( "Mary is dealt %d, %d\nHer hand is: %d\n",
                   card1, card2, sum );
                   return totalHand;//return sum of hand
                   //Report game status and maintain sum of hand
                   switch ( sum of cards )
                        //Dealer asks player if he/she wants another card
                        System.out.println( "Do you want a hit?" );
                   if ( gameStatus == Status.HIT )
                        nextCard = 1 + randomNumbers.nextInt( 10 );
                        totalHand = nextCard + sum;
                        System.out.printf("Emily's next card is %d\nEmily's hand is: %d\n",      
                        nextCard, totalHand );
    }

    The following is not a constructor:
    public void Blackjack( String Alice, int Emily, int Matt, int Mary )
       //initializing variables in declaration
      Alice = dealer;
      Emily = player1;
      Matt = player2;
      Mary = player3;
    }Remove the word "void" to make it a constructor
    public Blackjack( String Alice, int Emily, int Matt, int Mary )And, your code doesn't make sense. When you make that into a constructor and run the constructor, you will do something like this:
    Blackjack game = new Blackjack("Alice", 1, 2, 3);But, when you run the constructor, dealer is 'null' [default value of String variable]; and player1, player2, and player3 are 0 [default value of int variable]. Your constructor essentially says:
    Alice = null;
    Emily = 0;
    Matt = 0;
    Mary = 0;It sets the parameters to new values, but only locally within the constructor. The instance variables don't get new values at all. You need to reverse the assignments:
    dealer = Alice;
    player1 = Emily;
    ...It doesn't make a lot of sense to name your parameters to the constructor with specific persons' names. Not sure what your int values for players are for, anyway. You should have a Player class, as someone else suggested. It should have a name that can be set by the person running your program. Your game could start by saying:
    What is the name of Player 1?
    What is the name of Player 2?
    What is the name of Player 3?Then use the names to generate messages in the program.

  • Shifting from procedural to object oriented

    Hi people,
    I've been programming in ABAP in a procedural fashion since I started, because that's the way I was taught. Now I want to slowly shift to object oriented development. I know and understand all object oriented concepts (please don't copy paste OOP explanations or links merely to get points). Problem is, in the projects i'm involved everything is done in the old fashion. There's no use of UML whatsoever. I believe it's very difficult to shift my mind to OOP (an already difficult task for someone programming procedural for years) if the analisys and design is not done with OO as the base, as additionally I have very little practical experience with OOP (using ALV classes and such). If every other programmer does things in procedural way, when the time comes to integrate programs, problems arise.
    I've been experimenting with OOP in my safe minisap at home, but in day to day work as pressure is put to finish programs on time, always procedural solutions come to mind.
    Do you have any advice on how to cope with this? Can you post your experience on this subject? Has someone gone through this same problems?
    Many thanks.

    Hello Alejandro
    When I started with object-oriented ABAP programming about 2 years ago I made horrible mistakes in my classes and interfaces. However, I have my lessons learnt from these mistakes and improved my skills and knowledge step by step.
    I have 3 recommendations for you:
    <b>(1) Start now!</b>
    Do not expect to develop perfect interfaces and classes from the very beginning. Understanding Object-Orientation takes its time.
    <b>(2) Start with simple objects.</b>
    Interfaces (or classes) can be used to define globally visible constants. Your first classes may contain only static methods. Yet while developing these "simple" objects you will get familiar with the class builder (SE24).
    <b>
    (3) Make heavy use of SAP standard classes.</b>
    Before creating your own class(es) make a comprehensive search for available standard classes (of course, if you are dealing with custom-developed business objects you have to create your own classes).
    For example, if you have to work with purchase orders have a look at the following classes:
    - CL_PO_HEADER_HANDLE_MM
    - CL_PO_ITEM_HANDLE_MM
    If you create an instance of CL_PO_HEADER_HANDLE_MM you will have thousands of coding lines at your fingertip (e.g. method IF_PURCHASE_ORDER_MMGET_DATA returns the header data, method IF_PURCHASE_ORDER_MMGET_ITEMS returns the  order items -> no need of coding, just CALLING).
    Finally, you may have a look at the following examples:
    <a href="https://wiki.sdn.sap.com/wiki/display/profile/2007/07/09/UnderstandingABAPObjects">Understanding ABAP Objects</a>
    <a href="https://wiki.sdn.sap.com/wiki/display/profile/2007/07/09/MessageHandling-FindingtheNeedleintheHaystack">Message Handling - Finding the Needle in the Haystack</a>
    <a href="https://wiki.sdn.sap.com/wiki/display/Snippets/UnifiedAccesstoAllHR+Infotypes">Unified Access to All HR Infotypes</a>
    Regards
      Uwe

  • 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

  • What are the basic pillars of Object Oriented Programming?

    there are 3 pillars of OOP which are Encapsulation, inheritance, polymorphism, but i heard lot's of people even companies software engineers use abstraction is a pillar, i haven't find it from MSDN why abstraction is not a pillar ?

    Whereas encapsulation, inheritence and polymorphism are specific implementation details of OOP (i.e. the key ideas that make programming
    object-oriented), abstraction is a high-level way of looking at your overall application design.
    For example, in a simple database application you would not want to write your code so that your user-interface, business logic, and database code was all hard-coded and "tied" to each other.
    Ideally you would think about your design and try to plan your application so that your user-interface code is independent of your business logic code (which can be "plugged-in" and/or changed as necessary), which is again independent of your database
    code such that you could even switch to a different database and only need to change that one part of your code-base.
    As an example, you might not pass a class representing some business logic directly into your user-interface code. Rather, you may want to create an interface representing a generic way of representing your logic that could be re-used by lots of business
    classes. It is then this interface that could be used by your UI code or database code to validate data, rather than specific classes. Then you could create more classes in future that just have to implement the same interfaces, knowing that the rest of your
    code would not need to change. This is just one aspect of "abstraction".
    If you do a search for "application design patterns" or "object-oriented design patterns" you will find plenty of articles and books on how to go about doing this.

  • Who has the book:Object-Oriented Programming with ABAP Objects

    Hello everyone
    Now i want to learn ABAP OO,and Lots' of guys told me that the book  Object-Oriented Programming with ABAP Objects is realy a good book.but i searched on the net,and could not got PDF of this book,could some one gave me the net address if you know where to download the book or send me to my Mailbox:<email id removed by moderator>,I will very glad to receive any response from you,
    of course,if you have some advise on how to learn ABAP OO or some other material ,hope you could share your meaning with me, hope to receive your response.
    Best regards!
    From Carl
    Moderator message : Moved to career center.
    Edited by: Vinod Kumar on Aug 27, 2011 9:21 AM

    I'm sure you're not asking for illegal, "free" downloads. You can legally purchase the book, also in electronic format, at sap-press.com
    Thomas

  • 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.

  • Trying to understand object oriented programming

    Hi all,
    I'm new to programming and I'm trying to learn C and Objective-C to eventually write an iPhone/iPad app.
    I want to make sure I'm understanding some fundamental Object Oriented principles and so I'm starting with a very basic program.
    I've produced a class called CartesianPoint which has an x and y variable plus methods to set and return these variables and also a method to calculate the magnitude from the origin.
    What I would like to do now is to extend the program to have a CartesianVector class.
    I'm a little unsure as to whether a Vector is a subclass of a Point or whether a Point is a subclass of a Vector... or neither?
    Secondly, I'm a little unsure of how to implement the vector class to use two point objects. How should the header and implementation files be set up to receive point objects from the main.m program?
    I'd like to also try and extend the program to include other ways of defining a vector (i.e. origin, unity vector and magnitude).... and then use the vectors to build 2D shapes.
    Many thanks,
    Glyn
    Message was edited by: GlynC
    Message was edited by: GlynC

    Hi Glyn -
    I agree with William and would vote for "neither". I see a subclass as a specialization of its superclass, not, for example, something contained by its superclass. A container relationship might apply to a subview and its superview, yet the class of the superview could be a specialization of the subview's class so the subview's class might be the parent of the superview's class. The classic example of cat as a subclass of animal (cat:animal) can be misleading if we see the relationship as member:group. Cat is a subclass of animal because it's a specialization.
    Also ask, "What's accomplished by making a subclass"? Does the subclass want to use all or most of the parent's instance variables and methods? Could the job be done any other way? Are any of those ways simpler or do they lead to more reusable code?
    One of the best examples (from the Cocoa docs?) is about a programmer who needs a specialized array. A newbie might immediately attempt a subclass of NSArray (a rather tricky subclassing job as it happens). In most cases however, the correct solution would be a class which includes an NSArray* type instance variable.
    Hope some of the above is helpful!
    \- Ray

  • Object-oriented programming: state and behaivor

    First of all, sorry for my level english.
    In Object-Oriented programming, should an object save always some state?
    What about session stateless bean service? What is the sense?
    These objects have only behaivour and not state.
    Perhaps, the sense is that you can send a message to this object, in oposite of a static methods in utility class?
    Thanks and regards.

    I suppose you could argue that if it doesn't have any state, then it's not really an "object" in the OOP sense, but who cares, really.
    Personally, I use state and behavior as a way to help clarify the responsibilities of various classes in the system, and if I see a codebase with a lot of objects with state but no behavior or behavior but no state, then it's a a red flag that it's a messy, poorly-thought-out design (and it usually turns out to be exactly that). The whole point of OOP (IMHO) is encapsulation, and bundling state and behavior together makes things encapsulated (you can prove that state changes only in certain areas in certain circumstances). Encapsulation makes for more easily maintainable code.
    It's easy to spot the blue squares in a Mondrian. It's difficult to spot the blue bits in a Pollock. The former is well-encapsulated OOP and the latter is poorly-encapsulated spaghetti code.
    That said, it's not the end of the world if you have a static utility class here and there.

  • Object-Oriented Programming

    I'm working on a code associated with object-oriented programming:
    The StreetAddress class has this constructor:
    StreetAddress( String street, String city,
                   String state, String zip );
    and the following methods:
    void SetStreet( String street ); and String GetStreet();
    void SetCity( String city); and String GetCity();
    void SetState( String state ); and String GetState();
    void SetZIP( String zip ); and String GetZIP();
    String MailingLabel();.
    The last of these returns the mailing address in the following form:
    street
    city, state zipand this is what i have so far:
    public class StretAddress
      private String myStreet;
      private String myCity;
      private String myState;
      private String myZip;
      public StreetAddress( String street, String city, String state, String zip)
        myStreet = street;
        myCity = city;
        myState = state;
        myZip = zip;
      public String getStreet() 
          return myStreet;
      public void SetStreet( String street )
        myStreet = street;
      public String getCity()
          return myCity;
      public void SetCity( String city )
        myCiy = city;
      public String getState()
         return myState;
      public void SetState( String state )
        myState = state;
      public String getZip()
        return myZip;
      public void SetZip( String zip )
        myZip = zip;
      public String MailingLabel()
      System.out.println(street \n city, state + " " + zip);
    }I have no idea what to do now, can someone please help me with this?

    ejp wrote:
    personally, i don't think you need all four in order to be object-oriented.Without all four it might be class-based, or object-based, but not object-oriented. See Peter Wegner's paper which defined all this in 1987:
    http://www.cse.msu.edu/~stire/cse891f04/wegner.pdf
    With all due respect, I find this "definition" more meaningful:
    http://www.youtube.com/watch?v=bfx7tvGisbA

  • Object Oriented Programming concepts

    Hi Friends,
    I need your help to understand the Object Oriented Programming concepts.
    Please help me…
    Thanks,
    Fl4syed

    Hi,
    We can learn oops concepts very easily.Refering some books and search this concepts in some websites related to it.I think the author Robert lafore of oops is one of the best way to learn oops concepts.

  • Object Oriented Programming features

    Hello,
    i want to know more about Object Oriented Programming features, actually i have basic knowledge on Polymorphism, abstraction, DataHidding, Encapsulation, Inheritance. I know the basic bookish definition of these, but can u people give me the definition in terms of java program or any definition which i can co relate with java program.
    ex. Class is an example of encapsulation.
    Thanks.

    RGEO wrote:Hello,
    i want to know more about Object Oriented Programming features, actually i have basic knowledge on Polymorphism, abstraction, DataHidding, Encapsulation, Inheritance. I know the basic bookish definition of these, but can u people give me the definition in terms of java program or any definition which i can co relate with java program.
    ex. Class is an example of encapsulation.
    Thanks.see if we talk about encapsulation ----which means data hiding....now this can b expalined by the following example:
    class Rect {
    protected int len,br;
    public void getdata()
    len=14;
    br=20;
    public int area()
    return len*br;
    class box extends Rect
    private int h;
    public void getdata()
    super.getdata();
    h=56;
    System.out.println("the height is :"+h);
    public int volume()
    return len*br*h;
    {color:#ff0000}class inheritance
    {color}
    {color:#ff0000}public static void main(String[] args)
    box obj=new box();
    obj.getdata();
    System.out.println("volume of box is:"+obj.volume());
    }{color}
    In the above example we are showing inheritance alongwith encapsulation and it goes like this:
    we are able to view the result through main methods i.e. we call our method in main method with the help of objects....so we can say that whatever a user is showing he is showing through main method and not showing the logic because when we complie it then we are only shown the result and not the logic behind it.......This is known as encapsulation----showing relevant features and hiding rest all the things.
    Edited by: Namrata.Kakkar on Jul 29, 2009 10:46 PM

Maybe you are looking for