Thread: Sliders on Interfaces

Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31
  1. #11  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Suic View Post
    hmm, i don't think in this case a factory method gives me any adventage here, afaik in general they're used when the creation is complex, has defaults or i can give it a better name, also imo patching fields is bad(modifying the fields directly outside the constructor/an instance method) eg in the createSlider() method:
    Code:
    widgetSlider.minValue = minValue;
    I think a better than a factory method would be a Builder but that sounds like overkill to me in this scenario.
    correct me if im wrong on something tho, i just based this reply off some research
    Not really when they are complex. Tell me if I'm wrong here because I haven't messed with the interfaces for a while but the draw interface method is called when the interface is drawn presumably? If so we shouldn't need more than one instance per client.

    If that's the case the main advantage of using a static factory is that you can reduce object creation everytime the method is called by using a singleton. Idk what you mean about patching. Static factories are basically named constructors with a few other advantages. But you're right I didn't really need to do 'this' that should be in a private constructor. I forgot lmao
    Reply With Quote  
     

  2. #12  
    nice


    Join Date
    Jul 2014
    Posts
    740
    Thanks given
    382
    Thanks received
    562
    Rep Power
    4239
    Quote Originally Posted by Fire Cape View Post
    Not really when they are complex. Tell me if I'm wrong here because I haven't messed with the interfaces for a while but the draw interface method is called when the interface is drawn presumably? If so we shouldn't need more than one instance per client.

    If that's the case the main advantage of using a static factory is that you can reduce object creation everytime the method is called by using a singleton. Idk what you mean about patching. Static factories are basically named constructors with a few other advantages. But you're right I didn't really need to do 'this' that should be in a private constructor. I forgot lmao
    yes indeed, drawInterface() is what draws the interface and all it's components/children, but there should be a instance for each slider, think about it if i have 2 interfaces that use the slider components, they would share the same properties(minValue, maxValue, defaultValue, sprites) and the current value of the slider itself, which would be a problem because i'd want to use the slider for different things, eg interface 1 uses it to control brightness of the client and the other uses it to control the music volume of the client, if it was 1 instance, they both would share the same value in which case changing one of the sliders would affect the value of all sliders.

    edit: by patching i meant modifying the fields directly outside the constructor/an instance method
    Quote Originally Posted by Fire Cape View Post
    Not really when they are complex
    interesting, from almost every article that i read, it's usually used when you creating the object requires complex proccesses
    Reply With Quote  
     

  3. #13  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Suic View Post
    yes indeed, drawInterface() is what draws the interface and all it's components/children, but there should be a instance for each slider, think about it if i have 2 interfaces that use the slider components, they would share the same properties(minValue, maxValue, defaultValue, sprites) and the current value of the slider itself, which would be a problem because i'd want to use the slider for different things, eg interface 1 uses it to control brightness of the client and the other uses it to control the music volume of the client, if it was 1 instance, they both would share the same value in which case changing one of the sliders would affect the value of all sliders.

    edit: by patching i meant modifying the fields directly outside the constructor/an instance method

    interesting, from almost every article that i read, it's usually used when you creating the object requires complex proccesses
    Something like this is what I had in mind

    Code:
     
    	/**
    	* Create a widget slider instance
    	*/
    	private WidgetSlider slider = new WidgetSlider();
    	
    	/**
    	* Prevent the slider from being initialised twice
    	*/
    	private WidgetSlider() {
    	
    	}
    	
    	/**
    	* Construct a slider
    	*    @Param min The minimum value
    	*    @Param max The maximum value
    	*    @Param default The default value 
    	*    @Param background The background
    	*    @Param handle The handle
    	*/
    	private WidgetSlider(int min, int max, int default, SimpleImage background, SimpleImage handle) {
    		this.min = min;
    		this.max = max;
    		this.default = default;
    		this.background = background;
    		this.handle = handle;
    	}
    	
    	/**
    	* Return the single instance of widget slider
    	*    @Return The slider
    	*/
    	public static WidgetSlider createSlider() {
    		return slider;
    	}
    I wouldn't say that's complex.

    But you are right if you do have an interface with multiple needs for a slider it wouldn't really work. This would be more efficient for single use interfaces because it would reuse same instance, perhaps you could incorporate both for completion?

    Fyi they wouldn't share the same values as you are resetting them everytime it is drawn However if you need two sliders on one interface they would share.
    Reply With Quote  
     

  4. #14  
    nice


    Join Date
    Jul 2014
    Posts
    740
    Thanks given
    382
    Thanks received
    562
    Rep Power
    4239
    Quote Originally Posted by Fire Cape View Post
    I wouldn't say that's complex.
    i think u misunderstood me, what i meant is that the WidgetSlider class is really simple, all the constructor does is just initialize some variables, which is why i think a factory method is un-necessary here and i wouldn't gain anything from it, hence why a constructor fits the best imo.
    cause im pretty sure after doing some research u'd usually use a factory method when instantiating a complex constructor/object, a constructor fits better for something as simple as this.

    Quote Originally Posted by Fire Cape View Post
    But you are right if you do have an interface with multiple needs for a slider it wouldn't really work. This would be more efficient for single use interfaces, perhaps you could incorporate both for completion?
    and i guess i could but seems unnecessary.
    Reply With Quote  
     

  5. Thankful user:


  6. #15  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Suic View Post
    i think u misunderstood me, what i meant is that the WidgetSlider class is really simple, all the constructor does is just initialize some variables, which is why i think a factory method is un-necessary here and i wouldn't gain anything from it, hence why a constructor fits the best imo.
    cause im pretty sure after doing some research u'd usually use a factory method when instantiating a complex constructor/object, a constructor fits better for something as simple as this.


    and i guess i could but seems unnecessary.
    Why even make the class at all if simplicity is purely the goal? Just put the values in the widget class?
    Reply With Quote  
     

  7. #16  
    nice


    Join Date
    Jul 2014
    Posts
    740
    Thanks given
    382
    Thanks received
    562
    Rep Power
    4239
    Quote Originally Posted by Fire Cape View Post
    Why even make the class at all if simplicity is purely the goal?
    i never said simplicity was purely the goal, but that the class is simple because constructing a slider only needs a few properties.
    Quote Originally Posted by Fire Cape View Post
    Just put the values in the widget class?
    what lol, why would i put it in the Widget class together with the other methods which wouldn't even belong there instead of making a class for it and only having the object there.
    Reply With Quote  
     

  8. #17  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Suic View Post
    i never said simplicity was purely the goal, but that the class is simple because constructing a slider only needs a few properties.

    what lol, why would i put it in the Widget class together with the other methods which wouldn't even belong there instead of making a class for it and only having the object there.
    widget slider has public access anyway?

    why even bother creating an object if you are going to ignore OO principles because they aren't as convenient? just put them in the widget class
    Reply With Quote  
     

  9. #18  
    nice


    Join Date
    Jul 2014
    Posts
    740
    Thanks given
    382
    Thanks received
    562
    Rep Power
    4239
    Quote Originally Posted by Fire Cape View Post
    widget slider has public access anyway?

    why even bother creating an object if you are going to ignore OO principles because they aren't as convenient? just put them in the widget class
    im not ignoring OO principles because they aren't as convenient, in this case yes the only reason i made it public is cause i wanted to quickly create it and was too lazy to generate getters/setters if i made it private, but overall i just forgot to refactor it at the end, i did refactor it after ur first reply but didn't bother to edit the code in my post at that moment, but putting all of it in the widget class is way stupider than having the widgetSlider field public because that simply wouldn't make sense compared to it being an object that i create in my Widget class
    Reply With Quote  
     

  10. #19  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Suic View Post
    im not ignoring OO principles because they aren't as convenient, in this case yes the only reason i made it public is cause i wanted to quickly create it and was too lazy to generate getters/setters if i made it private, but overall i just forgot to refactor it at the end, i did refactor it after ur first reply but didn't bother to edit the code in my post at that moment, but putting all of it in the widget class is way stupider than having the widgetSlider field public because that simply wouldn't make sense compared to it being an object that i create in my Widget class
    Ok but just pointing out the 'easy' solution isn't always the best even though it works. Just look at Apollo, very complex in parts and could be done so much easier, but it is done properly not easily.
    Reply With Quote  
     

  11. #20  
    nice


    Join Date
    Jul 2014
    Posts
    740
    Thanks given
    382
    Thanks received
    562
    Rep Power
    4239
    Quote Originally Posted by Fire Cape View Post
    Ok but just pointing out the 'easy' solution isn't always the best even though it works. Just look at Apollo, very complex in parts and could be done so much easier, but it is done properly not easily.
    i understand that, altho i don't see anything that could be done much better in the code currently(other than making the field private and using getters/setters instead which i already did)

    edit: i do appreciate constructive criticism but regarding ur factory method suggestion im just saying that in this case it wouldn't really give me any adventages.
    Reply With Quote  
     

Page 2 of 4 FirstFirst 1234 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. Replies: 5
    Last Post: 01-02-2009, 05:33 AM
  2. Replies: 13
    Last Post: 05-10-2008, 12:58 AM
  3. Replies: 17
    Last Post: 04-28-2008, 01:10 PM
  4. Fading on interfaces / displays and such
    By Clienthax in forum RS2 Client
    Replies: 15
    Last Post: 04-12-2008, 03:02 PM
  5. Replies: 30
    Last Post: 02-10-2008, 04:48 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
  •