Thread: We need an API

Page 9 of 17 FirstFirst ... 7891011 ... LastLast
Results 81 to 90 of 164
  1. #81  
    Banned
    Join Date
    Mar 2012
    Posts
    11
    Thanks given
    0
    Thanks received
    1
    Rep Power
    0
    Quote Originally Posted by super_ View Post
    stop abusing accessor methods and learn what an INI file is, because that looks more like yaml
    I'm aware of INI file format. I was demonstrating a "mock" format, a format that is dependent on the preference of the developers.

    The use of accessor methods, also, to retrieve some encapsulated (and unable to be accessed otherwise) object or primitive is not abuse. It's even suggested by many of Java's library authors.
    Reply With Quote  
     

  2. #82  
    Renown Programmer
    veer's Avatar
    Join Date
    Nov 2007
    Posts
    3,749
    Thanks given
    354
    Thanks received
    1,367
    Rep Power
    3032
    Code:
    getServer().getEventManager().dispatchEvent(new ExampleEvent());
    can you tell me why you're encapsulating "server" here? especially when you presumably have direct access to the field? do you even know what the purpose of encapsulation is?
    i'm not saying that all uses of accessor methods are bad; instead, i'm arguing that all abuses of them are bad. yours are no exception.

    [Only registered and activated users can see links. ]
    Correct object-oriented design requires an object to encapsulate and hide its data, and to expose methods that are verbs acting on the object (not on individual properties of the object). The large majority of accessors are nouns — nothing more than pointless proxies for direct access to the object’s private data.
    [Only registered and activated users can see links. ] (read the feedback)

    [Only registered and activated users can see links. ]
    The idea behind using getters and setters is to be able to perform other behavior than just setting a value. This practice is recommended because there are a multitude of things you might want to retrofit into your class.

    Common reasons to use a setter (there are probably more):

    • Validation: not all values allowed by the type of the variable are valid for the member: validation is required before assignment.
    • Invariants: dependent fields might need to be adjusted (e.g. re-sizing and array might require re-allocation, not just storing the new size).
    • Hooks: there is extra work to perform before/after assignment, such as triggering notifications (e.g. observers/listeners are registered on the value).
    • Representation: the field is not stored in the format "published" as getters and setters. The field might not even stored in the object itself; the value might be forwarded to some other internal member or stored in separate components.

    If you think your code will never, ever use or require any of the above, then writing getters and setters by principle is definitely not good practice. It juste results in code bloat.
    [Only registered and activated users can see links. ]
    Fact is, Getters/setters have nothing to do with encapsulation. Here the data isn't more hidden or encapsulated than it was in a public field. Other objects still have intimate knowledge of the internals of the class. Changes made to the class might ripple out and enforce changes in dependent classes. Getter and setter in this way are generally break encapsulation. A truly well-encapsulated class has no setters and preferably no getters either. Rather than asking a class for some data and then compute something with it, the class should be responsible to compute something with its data and then return the result.
    educate yourself and stop writing bad smelly code.
    Reply With Quote  
     

  3. Thankful users:


  4. #83  
    Banned
    Join Date
    Mar 2012
    Posts
    11
    Thanks given
    0
    Thanks received
    1
    Rep Power
    0
    Quote Originally Posted by super_ View Post
    Code:
    getServer().getEventManager().dispatchEvent(new ExampleEvent());
    can you tell me why you're encapsulating "server" here? especially when you presumably have direct access to the field? do you even know what the purpose of encapsulation is?
    i'm not saying that all uses of accessor methods are bad; instead, i'm arguing that all abuses of them are bad. yours are no exception.

    [Only registered and activated users can see links. ]


    [Only registered and activated users can see links. ] (read the feedback)

    [Only registered and activated users can see links. ]


    [Only registered and activated users can see links. ]


    educate yourself and stop writing bad smelly code.
    Code:
    getServer().getEventManager().dispatchEvent(new ExampleEvent());
    is to be used as, again, pseudo for what a user might implement. As a user implementation, therefore, they do not have direct access to the field.

    Even though using accessor methods inside private code adds a tiny instruction overhead, an extending class can redefine what private code refers too, which is really good for expanding a class that doesn't directly provide the means for expanding its private code. In fact, if an API writer does intend on users extending classes, and may want users to change some reference to some objects that are also used within the super class' private code... using a non-final accessor method is probably the best solution.

    In the case where such accessor methods are final, I agree, there is no point to refer to them within private code.

    EDIT: And oh yeah, one last thing I forgot to mention. The reason a user might hold onto an instance of Server (assumed) is to avoid global state and ugly code as seen in usages of singletons.
    Reply With Quote  
     

  5. #84  
    REGISTERED MEMBER RAT DONOR MORE COMING

    Major's Avatar
    Join Date
    Jan 2011
    Posts
    3,002
    Thanks given
    1,295
    Thanks received
    3,525
    Rep Power
    5000
    Quote Originally Posted by Ignatius Baccus View Post
    EDIT: And oh yeah, one last thing I forgot to mention. The reason a user might hold onto an instance of Server (assumed) is to avoid global state and ugly code as seen in usages of singletons.
    Why the hell would you create multiple instances?
    Reply With Quote  
     

  6. #85  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,602
    Thanks given
    235
    Thanks received
    971
    Rep Power
    1244
    Quote Originally Posted by Major View Post
    Why the hell would you create multiple instances?
    he wouldn't. it's just that he probably read somewhere that it's bad design which i guess i could see how.

    the problem with not using accessors is that it looks kind of retarded. the parenthesis kind of adds some aesthetic value.

    Code:
    public class RippleNipple
    {
    	private boolean rippled = false;
    	public boolean nippled = true;
    	
    	public boolean getRippled()
    	{
    		return rippled;
    	}
    }
    
    ...
    
    RippleNipple rn = new RippleNipple();
    System.out.println(rn.getRippled());
    System.out.println(rn.nippled);
    
    boolean test = rn.nippled;
    test = rn.getNippled();
    .
    Reply With Quote  
     

  7. #86  
    Banned
    Join Date
    Mar 2012
    Posts
    11
    Thanks given
    0
    Thanks received
    1
    Rep Power
    0
    Quote Originally Posted by Supah Fly View Post
    he wouldn't. it's just that he probably read somewhere that it's bad design which i guess i could see how.

    the problem with not using accessors is that it looks kind of retarded. the parenthesis kind of adds some aesthetic value.

    Code:
    public class RippleNipple
    {
    	private boolean rippled = false;
    	public boolean nippled = true;
    	
    	public boolean getRippled()
    	{
    		return rippled;
    	}
    }
    
    ...
    
    RippleNipple rn = new RippleNipple();
    System.out.println(rn.getRippled());
    System.out.println(rn.nippled);
    
    boolean test = rn.nippled;
    test = rn.getNippled();
    You're convoluted if you thought I was arguing against access methods, and more convoluted to say that the only good accessor methods do is make code "look nice"
    Reply With Quote  
     

  8. #87  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,602
    Thanks given
    235
    Thanks received
    971
    Rep Power
    1244
    Quote Originally Posted by Ignatius Baccus View Post
    You're convoluted if you thought I was arguing against access methods, and more convoluted to say that the only good accessor methods do is make code "look nice"
    you're the one assuming i was even talking about you in regards to that. you're also the one that is putting those words in my mouth. i never said that "the only good accessor methods do is make code look nice." you said that. i said that i think they look better than without just for the simple fact that the parenthesis make it look better. it's not some kind of revolutionary thought so try not to get too worked up about it.

    if you're going to start nitpicking everything someone says then at least make sure they actually said it.
    .
    Reply With Quote  
     

  9. #88  
    Banned
    Join Date
    Mar 2012
    Posts
    11
    Thanks given
    0
    Thanks received
    1
    Rep Power
    0
    Quote Originally Posted by Major View Post
    Why the hell would you create multiple instances?
    I had forgotten to reply to you. And a reason for multiple instances of a Server (environment container...) is, well, to represent multiple servers. Anyway, that's completely irrelevant to the pseudo-code I posted in the first place. It was to show an example user implementation, where global state is ignored. Usage of the singleton pattern arises the issue of global state and ugly (cryptic) code, in general.

    Quote Originally Posted by Supah Fly View Post
    you're the one assuming i was even talking about you in regards to that. you're also the one that is putting those words in my mouth. i never said that "the only good accessor methods do is make code look nice." you said that. i said that i think they look better than without just for the simple fact that the parenthesis make it look better. it's not some kind of revolutionary thought so try not to get too worked up about it.

    if you're going to start nitpicking everything someone says then at least make sure they actually said it.
    "the problem with not using accessors is that it looks kind of retarded. the parenthesis kind of adds some aesthetic value." (Supah Fly)
    Reply With Quote  
     

  10. #89  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,602
    Thanks given
    235
    Thanks received
    971
    Rep Power
    1244
    "the problem with not using accessors is that it looks kind of retarded. the parenthesis kind of adds some aesthetic value." (Supah Fly)
    i don't get why you're assuming that i mean something i didn't actually say or even imply. it's not some riddle. i mean exactly what i said. in my opinion it does look a little weird and i like how access methods look in comparison. that's all that those words meant.

    just because i like the color blue doesn't mean that i hate the color pink. it just means that i like the color blue.
    .
    Reply With Quote  
     

  11. #90  
    Renown Programmer
    veer's Avatar
    Join Date
    Nov 2007
    Posts
    3,749
    Thanks given
    354
    Thanks received
    1,367
    Rep Power
    3032
    Quote Originally Posted by Ignatius Baccus View Post
    Code:
    getServer().getEventManager().dispatchEvent(new ExampleEvent());
    is to be used as, again, pseudo for what a user might implement. As a user implementation, therefore, they do not have direct access to the field.
    first of all, pseudo is an adjective not a noun:
    [Only registered and activated users can see links. ]

    now, you completely missed the question. i understand the line of code is a template for how to dispatch an event in your server. the problem i was citing was your call to (i'm assuming it's going through the superclass) super.getServer()... presumably you desire access to the field, so why are you going through getServer()? the field is probably private in the superclass -- bu why? it's clear you want to expose it to the subclass, so why not make it a protected field? or, better yet, you should pass it as a sort of context to the subclass or its methods.

    Even though using accessor methods inside private code adds a tiny instruction overhead, an extending class can redefine what private code refers too, which is really good for expanding a class that doesn't directly provide the means for expanding its private code. In fact, if an API writer does intend on users extending classes, and may want users to change some reference to some objects that are also used within the super class' private code... using a non-final accessor method is probably the best solution.

    In the case where such accessor methods are final, I agree, there is no point to refer to them within private code.
    i can't read this. judging by your last sentence i'm assuming you're saying accessors are good because they hide underlying details and help decouple code, as these details could be changed by subclasses and what not. that's great, however i don't see how this applies in your situation.

    EDIT: And oh yeah, one last thing I forgot to mention. The reason a user might hold onto an instance of Server (assumed) is to avoid global state and ugly code as seen in usages of singletons.
    so you want to avoid (static) global state, but not through singletons (which are still global) -- good on you. i don't think the solution is at all what you're doing; instead, i've tended to pass around a context (though i expect services to hold on to it if they need it):
    Code:
    package veer.luna.service;
    
    import veer.luna.Application;
    import veer.luna.ApplicationContext;
    
    public interface Service {
    
        public void initialize(ServiceContext context);
    
        public void start();
    
        public void stop();
    
        public void destroy();
    }
    see more:
    [Only registered and activated users can see links. ]

    [Only registered and activated users can see links. ]

    that being said, be wary that you don't abuse the context pattern as well.
    [Only registered and activated users can see links. ]

    note that sometimes its easier and more streamlined to code as if you're working with global (static) data. i've only dabbled very briefly with an rs bot a couple years back and i ended up utilizing a mix between the singleton and context patterns via thread-local storage. i did something like:

    Code:
    class SlaveContext {
        
        private static final ThreadLocal<SlaveContext> context = ...;
    
        public static SlaveContext get() {
            return context.get();
        }
    
        ...
    }
    Code:
    class Npcs {
    
        public static Collection<Npc> local(Filter<? super Npc> filter) {
            SlaveContext context = SlaveContext.get();
            /* create the filtered sparse list */
            ...
        }
    
        ...
    }
    so then you'd have a script do e.g.
    Code:
    Filter<Character> filter = CharacterFilters.minimumLevel(50);
    for (Npc npc : Npcs.local(filter)) {
        ...
    }
    note that scripters need to directly fiddle with any shared data state at all, which is good.

    edit: sorry for going so off-topic... i have a tendency to mentally drift.
    Reply With Quote  
     

Page 9 of 17 FirstFirst ... 7891011 ... LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. Skills API?
    By Mister Maggot in forum RS2 Server
    Replies: 12
    Last Post: 08-24-2010, 01:17 AM
  2. What's the best API?
    By TriConnectivity™ in forum Help
    Replies: 12
    Last Post: 06-15-2010, 11:52 PM
  3. what API does RID use?
    By sylas in forum Application Development
    Replies: 17
    Last Post: 05-16-2010, 11:22 PM
  4. Networking Api
    By Karilz in forum Voting
    Replies: 6
    Last Post: 05-04-2010, 05:55 AM
  5. Which API?
    By Discardedx2 in forum RS 503+ Client & Server
    Replies: 35
    Last Post: 04-09-2010, 01:07 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •