Welcome to the Java Programming Forums


The professional, friendly Java community. 21,500 members and growing!


The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.


>> REGISTER NOW TO START POSTING


Members have full access to the forums. Advertisements are removed for registered users.

Page 1 of 2 12 LastLast
Results 1 to 25 of 26

Thread: functional programming with objects

  1. #1
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default functional programming with objects

    I'm a big object oriented programmer myself, but I currently work for a company where my two immediate supervisors are big C++ guys who were raised on functional programming. They claim they want to take advantage of object oriented design concepts, but it's been a real struggle.

    Then they do create an object the entire object is generally based on what the function does. For example one of them wanted to render something to a screen so he created an object called Renderer who's only method was called rendor. That function took in a pointer to a screen object. I tried to explain to him that what he really wanted to do was create a function on the screen object called render.

    Another guy wanted to do a search of some purchase order files to validate some string inputs. he had his function return an object called SearchResults. Once again naming it more after what it did than what it actually was. I tried to explain that we should really call that object PurchaseOrder since that more accurately described what it was to no avail.

    It seems like this has to be a common thing that functional programmers struggle with when moving to object oriented design, but I'm not finding any good reference material or tutorials that explain it and since I don't really have seniority and I'm kind of out numbered it's really hard to convince these guys of how best to design their objects. Does anybody know of any good online papers I could direct them to?


  2. #2
    Forum VIP
    Join Date
    Jul 2010
    Posts
    1,676
    Thanks
    25
    Thanked 329 Times in 305 Posts

    Default Re: functional programming with objects

    Well, you could start with the basic principle of OOP: Objects are nouns, and Methods are verbs. Your Object should never be a verb, and your Methods should never be nouns.
    NOTE TO NEW PEOPLE LOOKING FOR HELP ON FORUM:

    When asking for help, please follow these guidelines to receive better and more prompt help:
    1. Put your code in Java Tags. To do this, put [highlight=java] before your code and [/highlight] after your code.
    2. Give full details of errors and provide us with as much information about the situation as possible.
    3. Give us an example of what the output should look like when done correctly.

    Join the Airline Management Simulation Game to manage your own airline against other users in a virtual recreation of the United States Airline Industry. For more details, visit: http://airlinegame.orgfree.com/

  3. #3
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    Right, but they get around that by adding "er" to the end of a verb and turn it into a noun. They say "I want to render so I create a Renderer." I want to search so I'll create a Searcher. Technically it is a noun even though it's based entirely off of a verb.

  4. #4
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    I wouldnt say anything is wrong with that. It might be different to what you prefer, but in the end its all just personal opinion. Sometimes its good to delegate methods to other classes because it allows you to swap functionality at run-time.

  5. #5
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    But if you're going to do that why bother object oriented programming at all? You're just functional programming using objects. If you're going to create an object who's only purpose is to execute one function then why not just write the function?

  6. #6
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    Why not put it into an object? Thats not a good way to argue. You can always ask "why not this / why not that".
    Maybe they will expand the class later on. Maybe it only has one function right now but in the future it might get more then that.

    I am not a friend of having classes with only 1 method either. It does not seem to be right. But sometimes that one method is really all that is needed.
    I can very well see the use of a "RenderingJob" class with only the method "render". Then you can have many classes sub-class RenderingJob and change the way they render themselfs. It would be a nice way of implementing different designs / styles within a graphic heavy application.

  7. #7
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by Cornix View Post
    Why not put it into an object? Thats not a good way to argue. You can always ask "why not this / why not that".
    Maybe they will expand the class later on. Maybe it only has one function right now but in the future it might get more then that.
    Except you can't because they named it specifically after what it does. Therefore adding additional functionality would make it into something else. If you had and objected called Runner with a function called run and you tried to add a function called jump to it the object wouldn't make any sense. It's not just a Runner any more it's a RunnerJumper, or an Athlete. A runner is a combination of a thing, and an action. It's person who runs. The correct way of designing that object would be to have an object called person, with a function called run() on it. If they then later wanted to add a jump() method they could and it would all still make sense.

    Quote Originally Posted by Cornix View Post
    I am not a friend of having classes with only 1 method either. It does not seem to be right. But sometimes that one method is really all that is needed.
    I can very well see the use of a "RenderingJob" class with only the method "render". Then you can have many classes sub-class RenderingJob and change the way they render themselfs. It would be a nice way of implementing different designs / styles within a graphic heavy application.
    A RenderingJob object might make sense, in the sense that it's a list of instructions for how to rendor something, but ultimately you'd still want to pass that RenderingJob into the rendor method on a screen.

    For example we have a Printer Class and a PrintJob class. In this case however the Printer is an actual real world device, which is named specifically after the one thing it does. A Printer that's not printing is still called a printer. Whereas a Runner that's not Running is just a Person. Even if running is what they do for a living they still do other things, and we would be limiting the functionality of our object if we called it a Runner.

  8. #8
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    I think you are making it more complicated then is necessary. I see no problem with having a RenderingJob that renders itself. Its just an other perspective on the same problem. There is no final answer, there is only subjective opinions.

  9. #9
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    I think that if you want to call yourself an object oriented programmer then there certainly is a final answer. A function on an object is something that you do to the object. Render isn't something you do to a RenderingJob it's something you do to a Screen and the Job holds the information about what is to be Rendered. To put it another way a RenderingJob is useless unless you know what you're rendering to. A RendoringJob must know information about the screen in order to even attempt the process of rendering. A Screen however doesn't need to know anything about Rendering in order to simply exist.

    In the same way I can't create a Runner object unless I know what is running. If it's a person I need to call move_legs(), but if it's a car I need to call turn_wheels(), if it's a fan I need to call spin_blades(), if it's presidential candidate I need to call form_political_action_committee(). I can create a Person object without any knowledge whatsoever about what it's ultimately going to do. I know with absolutely certainty that anything it does will at minimum require knowledge about that person.

    So if you truly consider yourself an object oriented programmer establishing the nouns, the tangible things that exist is paramount. If you're just making up things based on what you are doing your a functional programmer whether you realize it or not.

  10. #10
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    I disagree.
    What you describe is not object oriented programming. You seem to have some kind of religion you are trying to defend.

    As a programmer I am not an artist. I am a service provider. I have a job to do and it is my responsibility to choose the best solution for a given problem.
    If I decide that an abstract RenderingJob class is a good idea to have diverse and exchangeable designs then I will do it this way. If it works, is maintainable, self-explanatory and flexible, then its a good solution.

  11. #11
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by Cornix View Post
    I disagree.
    What you describe is not object oriented programming. You seem to have some kind of religion you are trying to defend.
    No, you really don't seem to understand object oriented programming. What you are talking about is functional programming. Your using an object, but ultimately your thinking is functional. You're focused on what you want to do, and everything is oriented around that.

    Quote Originally Posted by Cornix View Post
    As a programmer I am not an artist.
    You should try being both sometime.

    Quote Originally Posted by Cornix View Post
    I am a service provider. I have a job to do and it is my responsibility to choose the best solution for a given problem.
    If I decide that an abstract RenderingJob class is a good idea to have diverse and exchangeable designs then I will do it this way. If it works, is maintainable, self-explanatory and flexible, then its a good solution.
    Except it's not all that maintainable, self-explanatory, or flexible. Passing a Screen object into a RenderingJob is backwards. You're not modifying the RenderingJob you're modifying the Screen. In real life you wouldn't pass a screen into a RenderJob, you'd hand a RendorJob to a Screen. That's counter-intuitive to how a OOP would think. It's also not very maintainable or flexible because for everything you need to do to a screen you need a different object to perform that function which exists in a different compilation unit. This makes it difficult to take advantage of common code relating to a screen without exposing it to a wider audience than you want to. You also can't easily replace an implementation without having to touch potentially many objects.

  12. #12
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by ischuldt View Post
    No, you really don't seem to understand object oriented programming. What you are talking about is functional programming. Your using an object, but ultimately your thinking is functional. You're focused on what you want to do, and everything is oriented around that.
    You should read again what functional programming really is. What you say does not make sense.


    Quote Originally Posted by ischuldt View Post
    Passing a Screen object into a RenderingJob is backwards.
    I never said anything about that.

    Quote Originally Posted by ischuldt View Post
    You're not modifying the RenderingJob you're modifying the Screen. In real life you wouldn't pass a screen into a RenderJob, you'd hand a RendorJob to a Screen. That's counter-intuitive to how a OOP would think. It's also not very maintainable or flexible because for everything you need to do to a screen you need a different object to perform that function which exists in a different compilation unit. This makes it difficult to take advantage of common code relating to a screen without exposing it to a wider audience than you want to. You also can't easily replace an implementation without having to touch potentially many objects.
    Where do you take all these assumptions from? You have to be able to think more abstract, you cant blindly fill in the blanks as you please.

  13. #13
    Forum VIP
    Join Date
    Jul 2010
    Posts
    1,676
    Thanks
    25
    Thanked 329 Times in 305 Posts

    Default Re: functional programming with objects

    Passing a Screen object into a RenderingJob is backwards. You're not modifying the RenderingJob you're modifying the Screen. In real life you wouldn't pass a screen into a RenderJob, you'd hand a RendorJob to a Screen. That's counter-intuitive to how a OOP would think. It's also not very maintainable or flexible because for everything you need to do to a screen you need a different object to perform that function which exists in a different compilation unit. This makes it difficult to take advantage of common code relating to a screen without exposing it to a wider audience than you want to. You also can't easily replace an implementation without having to touch potentially many objects.
    Well, if we are talking about "real-world" situations, I would argue that you are handcuffing yourself if you work under the assumption that a given object knows how it should be rendered. In reality, your code might need to run on different devices which require different methods of rendering. For example: a desktop application and an Android app. In the "real-world", you would put all of your operational code in a library (or set of libraries, if need be), and you would have specially designed projects for each front-end. In order for all of this to work properly, you would need to rely somewhat on abstraction.
    For example, let's say your operation code library had these classes:
    /**
     * Shared Data is a singleton and stores runtime data.
     */
    public enum SharedData {
    	/**
    	 * The singleton instance.
    	 */
    	INSTANCE;
     
    	/**
    	 * The runtime instance of the manager.
    	 */
    	public static RenderJobManager renderJobManager;
    	/**
    	 * The list of rendering wrappers for each object.
    	 */
    	public List<RenderJob> renderJobs = new ArrayList<>();
    	/**
    	 * Adds a renderable object to the list.
    	 */
    	public void addRenderJob(Renderable addFor) {
    		RenderJob toAdd = renderJobManager.getRenderJob(addFor);
    		if(toAdd!=null) { 
    			renderJobs.add(toAdd);
    		}
    	}
    	/**
    	 * Renders all the objects.
    	 */
    	public void renderAll() {
    		for(RenderJob renderJob : renderJobs) {
    			renderJob.render();
    		}
    	}
    }
    /**
     * The interface for managing the RenderJob objects. To be
     * implemented by the front-end project.
     */
    public interface RenderJobManager {
    	public RenderJob getRenderJob(Renderable renderable);
    }
    /**
     * An abstract wrapper for the objects to render.
     */
    public abstract class RenderJob<T extends Renderable> {
    	protected T toRender;
     
    	public RenderJob(T toRender) {
    		this.toRender = toRender;
    	}
     
    	public abstract void render();
    }
    /**
     * The super class for all renderable objects.
     */
    public abstract class Renderable {
    	protected int x;
    	protected int y;
     
    	public Renderable(int x,int y) {
    		this.x = x;
    		this.y = y;
    		SharedData.INSTANCE.addRenderJob(this);
    	}	
    	public int getX() {
    		return this.x;
    	}	
    	public int getY() {
    		return this.y;
    	}
    }
    /**
     * One renderable class.
     */
    public class Object1 extends Renderable {
    	public Object1(int x,int y) {
    		super(x,y);
    	}
    }
    /**
     * A second renderable class.
     */
    public class Object2 extends Renderable {
    	public Object2(int x,int y) {
    		super(x,y);
    	}
    }
    When you create the library, you have no idea what devices you will be rendering for, so you implement all the rendering code on the front-end project.
    Now let's say we have a front-end project where we want to be able to create these objects and render them. We need to provide custom code for each object to render for whatever front-end specifications we have. That front-end project would look like:
    /**
     * The main runner class.
     */
    public class Runner {
    	public static void main(String[] args) {
    		SharedData.INSTANCE.renderJobManager = new CustomRenderJobManager();
    		List<Renderable> objects = new ArrayList<>();
    		objects.add(new Object1(0,0));
    		objects.add(new Object2(1,1));
    		objects.add(new Object1(3,3));
    		objects.add(new Object2(2,2));
    		SharedData.INSTANCE.renderAll();
    	}
    }
    /**
     * The wrapper for Object1.
     */
    public class RenderObject1 extends RenderJob<Object1> {
    	@Override
    	public void render() {
    		// render in some way
    	}
    }
    /**
     * The wrapper for Object2.
     */
    public class RenderObject2 extends RenderJob<Object2> {
    	@Override
    	public void render() {
    		// render in some way
    	}
    }
    /**
     * The custom front-end's RenderJobManager implementation.
     */
    public class CustomRenderJobManager implements RenderJobManager {
    	@Override
    	public RenderJob getRenderJob(Renderable renderable) {
    		if(renderable instanceof Object1) {
    			return new RenderObject1(renderable);
    		} else if(renderable instanceof Object2) {
    			return new RenderObject2(renderable);
    		}
    		return null;
    	}
    }

    Now, the question you will probably ask is: why use a wrapper for each object when we can add the render() method to the Renderable abstract class and override the objects instead of the wrappers?
    The answer to that is because it violates the MVC (Model-View-Controller) architecture pattern. The Renderable class is part of your Model, while the RenderJob class is part of your View. If you put the render() method in the Renderable class, you have an object which overlaps the Model and View parts of the pattern.

    This code is certainly far from a perfect design, but I just sort of threw this all together for example purposes. Thoughts?
    NOTE TO NEW PEOPLE LOOKING FOR HELP ON FORUM:

    When asking for help, please follow these guidelines to receive better and more prompt help:
    1. Put your code in Java Tags. To do this, put [highlight=java] before your code and [/highlight] after your code.
    2. Give full details of errors and provide us with as much information about the situation as possible.
    3. Give us an example of what the output should look like when done correctly.

    Join the Airline Management Simulation Game to manage your own airline against other users in a virtual recreation of the United States Airline Industry. For more details, visit: http://airlinegame.orgfree.com/

  14. #14
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,424
    My Mood
    Hungover
    Thanks
    144
    Thanked 635 Times in 540 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by ischuldt View Post
    I think that if you want to call yourself an object oriented programmer then there certainly is a final answer.
    Programming languages, programming patterns, programming paradigms, etc are all tools. No "real" programmer would "want to call themselves an object oriented programmer" any more than any real construction worker would call themselves "the hammer guy". (Unless he's Thor, I guess?)

    You learn these skills like a construction worker learns to use different tools, or how an artist learns to use different types of paint or pencils or paper or clay or whatever. Saying that one way is always better, or that somebody is *wrong* for thinking a certain way is *really* missing the point.

    Some people argue that Java isn't strictly OOP because it has primitives. So even what you're trying to make sound like a strict dichotomy is really more like a scale.

    I'm not really sure what you want us to say here- you've had several interesting points tossed your way, and all you've done is insult the posters (who, trust me, know what they're talking about).

    If all you want to do is complain about your coworkers, hey that's fine, but then please use the off-topic forum for that. If you want to get back on topic, please stop insulting the people who are trying to have an interesting conversation with you, please start listening to what they have to say and replying with something other than false arguments.

    If you keep simply ignoring what people are telling you and insulting them instead, I'm going to close this thread.

    Happy coding.
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  15. #15
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by Cornix View Post
    I never said anything about that.
    How exactly do you expect your rendering job to know how to render if it doesn't know what it's rendering to? Either the Job gets passed into Screen(what I'm saying you should do), or the Screen gets passed in to Job. There's no other way to do it.

    Quote Originally Posted by Cornix View Post
    Where do you take all these assumptions from? You have to be able to think more abstract, you cant blindly fill in the blanks as you please.
    No I think the problem here is that you are thinking too abstractly. Part of what is beautiful about OOP is that it allows you to model how the real world works. That helps make things more intuitive and prevents you from making silly mistakes by taking shortcuts. In the real world you could never pass an actual computer Screen into a RenderingJob, you'd send a RenderingJob to a Screen.

    --- Update ---

    Quote Originally Posted by aussiemcgr View Post
    Well, if we are talking about "real-world" situations, I would argue that you are handcuffing yourself if you work under the assumption that a given object knows how it should be rendered. In reality, your code might need to run on different devices which require different methods of rendering.
    Are you replying to me or Cornix? Because this is exactly what I'm trying to say. It makes no sense for an object to know how it's going to be rendered because it would need to know what it is being rendered to. The RenderJob might contain information about the shape to be rendered, which it could relay to a screen, android, iphone, whatever.

    --- Update ---

    Quote Originally Posted by KevinWorkman View Post
    Programming languages, programming patterns, programming paradigms, etc are all tools. No "real" programmer would "want to call themselves an object oriented programmer" any more than any real construction worker would call themselves "the hammer guy". (Unless he's Thor, I guess?)

    You learn these skills like a construction worker learns to use different tools, or how an artist learns to use different types of paint or pencils or paper or clay or whatever. Saying that one way is always better, or that somebody is *wrong* for thinking a certain way is *really* missing the point.
    I'm not saying there is no place for functional programming. I'm saying that in the project we're working on clearly calls for objected oriented design, and in fact we are using objects. But if you're going to use objects you might as well use them how their supposed to be used. If you want to functional program use stand alone functions. Don't wrap a stand alone function up in and object and then call yourself an OOP.

    Quote Originally Posted by KevinWorkman View Post
    I'm not really sure what you want us to say here- you've had several interesting points tossed your way, and all you've done is insult the posters (who, trust me, know what they're talking about).
    I'm not trying to insult anybody here, but I think there is clearly some confusion coming from Cornix on what OOP is. You can say there is a scale between OOP and functional programming and I get that, but there are definite dividing lines where you're thinking has clearly become more functional and based on what he's saying it sounds like he's crossing them unless I'm misunderstanding what he's saying.

    --- Update ---

    Quote Originally Posted by aussiemcgr View Post
    This code is certainly far from a perfect design, but I just sort of threw this all together for example purposes. Thoughts?
    So I believe I followed all that, but the question and problem I have with it is that each of your RendorJob's has to have information about whatever device you are rendering to, so if you want to change what device your rendering to you have to update all your RenderingJob's. If you were passing your Renderable object right into a single Screen then the code for determining how to actually display things on that device would be housed in one place. To me a RenderJob, is just a list of Renderable objects that all need to be rendered at the same time.

  16. #16
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    First of all, you should *really* read the *definition* of functional programming again. What you call functional programming is not the same as what I call functional programming.

    Secondly, you are going way over board. Of course its always nice to try to model your program after real-life counterparts, but there is always only so much you can do. This is not magic, we can not create matter out of thin air.
    At some point your object relationships will become too complicated and verbose and instead of making things easier and more maintainable, you will get the opposite of that.

    Instead, you should try to analyse the problem at hand and decide how much object-orientation is too little or too much.



    For the sake of the RenderingJob argument, take this quick code example:
    public interface Graphics {
     
    	public void drawQuad(/* args and stuff*/);
     
    	public void drawTriangle(/* args and stuff*/);
     
    	public void drawLine(/* args and stuff*/);
     
    	// possibly many more methods...
     
    }
    public interface RenderingJob {
     
    	public void renderYourself(Graphics g);
     
    }
    public interface RenderingManager {
     
    	public void addRenderingJob(RenderingJob job);
     
    	public void removeRenderingJob(RenderingJob job);
     
    	public void renderAllJobs();
     
    	public Graphics getGraphics();
     
    }
    As you can see, RenderingJob's are added to a RenderingManager which will make all its jobs render themselfs to a Graphics object. (Compare the Swing painting mechanism)
    This is very much object-oriented programming by my definition. Its clean, and easy to understand. You need something rendered? Just create a new RenderingJob and add it to a RenderingManager.

  17. #17
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    I think you are making a couple significant mistakes here though. First, how do your graphics know how to render themselves unless they know what they are rendering themselves to? Is it a screen? A piece of paper? An Android an Iphone? The second is just in how you translate the spec.

    One of the goals of OOP is to make it easier to translate a Design Spec straight into an actual design in away that leaves little ambiguity between what the spec said and how things end up looking. This insures that no two developers are going to arrive at drastically different designs and therefore makes things more intuitive.

    If the spec says: "Render a shape to the screen." Every OOP developer reading that should end up with a virtually identical design.

    Forgive me I've been writting a lot of C++ lately so this will look a little odd, but you get the idea.

    class Shape {
    public:
        int x_coord();
        int y_coord();
        int height();
        int width();
        int color();
    };
     
    class Screen {
    public:
        void render(Shape x);
    };

    If the spec says "Render a series of Shapes to the Screen." you should get:

    class Shape {
    public:
        int x_coord();
        int y_coord();
        int height();
        int width();
        int color();
    };
     
    class RenderingSeries {
    public:
        void add_shape(Shape x);
         list<Shape> shapes();
    };
     
    class Screen {
    public:
        void render(Shape x);
     
        void render_series(RenderSeries x) {
             foreach(i in x.shapes()) {
                   render(i);
             }
        }
    };

    Obviously this is a little crude, but the idea here is that what the spec says should translate very easily in to a design, and any developer reading it should arrive at a very similar one. The nouns should go almost directly into objects, the verbs should become methods. If you're reading that spec, and coming up with a vastly different design you're doing something wrong.

  18. #18
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by ischuldt View Post
    First, how do your graphics know how to render themselves unless they know what they are rendering themselves to? Is it a screen? A piece of paper? An Android an Iphone?
    It simply doesnt matter. Its an interface, any kind of class can implement it. An OpenGL renderer, an Image (that will be rendered to the screen later), anything. Its not important for the design of the program. And its not important for the design of RenderingJobs.
    You just define what you want to have rendered in form of abstract methods (quads, triangles, lines, whatever) and the implementation will make sure that it gets rendered.

    Quote Originally Posted by ischuldt View Post
    The second is just in how you translate the spec.

    One of the goals of OOP is to make it easier to translate a Design Spec straight into an actual design in away that leaves little ambiguity between what the spec said and how things end up looking. This insures that no two developers are going to arrive at drastically different designs and therefore makes things more intuitive.
    You should try to elaborate this argument further. What seems to be ambiguous to you?



    ... code ...
    I dislike your style.
    Why should a Screen know what a Shape is? What does the Screen care?
    Why should a Shape know how that it has an X- and Y-coordinate? Or a color? Or a width or height? I wouldnt explain shapes as something that has a position and a size.
    What is the width and height of an ellipses? Or a triangle?

  19. #19
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by Cornix View Post
    It simply doesnt matter. Its an interface, any kind of class can implement it. An OpenGL renderer, an Image (that will be rendered to the screen later), anything. Its not important for the design of the program. And its not important for the design of RenderingJobs.
    You just define what you want to have rendered in form of abstract methods (quads, triangles, lines, whatever) and the implementation will make sure that it gets rendered.
    Essentially your graphics class is similar to what my screen class would be except it wouldn't draw itself, it would draw an object that it was given.

    Quote Originally Posted by Cornix View Post
    You should try to elaborate this argument further. What seems to be ambiguous to you?
    The fact that you and I read the same spec and come up with radically different designs is by definition ambiguous. It means that if you look at my design you will have trouble understanding it, and if I read your design I will have trouble understanding it. The goal of OOP is to insure that any two developers following oop design patterns would look at the same spec, and end up with an almost identical design. That way when I read yours it's more likely to make sense, and vice versa because they're so similar. That's why the process of translating nouns to objects and verbs to functions is so important. It keeps things from getting lost in translation.


    Quote Originally Posted by Cornix View Post
    I dislike your style.
    Why should a Screen know what a Shape is? What does the Screen care?
    Because the screen is what ultimately has to draw it. Shapes can't draw themselves in the real world. Shapes are just abstract concepts until they are put into the hands of something that can draw them. Ultimately the same reality is true of your design as well. The shape doesn't know what command the screen uses to draw a circle, and it shouldn't know. It doesn't need to. Only the screen needs to care.


    Quote Originally Posted by Cornix View Post
    Why should a Shape know how that it has an X- and Y-coordinate? Or a color? Or a width or height? I wouldnt explain shapes as something that has a position and a size.
    What is the width and height of an ellipses? Or a triangle?
    I just added some dummy fields to give you a feel for what I'm talking about it's not necessarily what members a shape should actually have. In fact you'd probably have a different rendor method for each shape you wanted to rendor.

  20. #20
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by ischuldt View Post
    Essentially your graphics class is similar to what my screen class would be except it wouldn't draw itself, it would draw an object that it was given.
    Seeing as your Screen renders shapes, perhaps it is. But I would argue that "Screen" is a bad name for it. A screen is something on which you see something. A screen is passive, you observe it, but it doesnt do anything but show itself. A screen doesnt know shapes or rendering or anything.
    However, Graphics could be output to a screen. Perhaps its not the best word either, but it is what Swing uses and I just borrowed the term.


    Quote Originally Posted by ischuldt View Post
    The fact that you and I read the same spec and come up with radically different designs is by definition ambiguous. It means that if you look at my design you will have trouble understanding it, and if I read your design I will have trouble understanding it. The goal of OOP is to insure that any two developers following oop design patterns would look at the same spec, and end up with an almost identical design. That way when I read yours it's more likely to make sense, and vice versa because they're so similar. That's why the process of translating nouns to objects and verbs to functions is so important. It keeps things from getting lost in translation.
    You can never achieve that. Once your program grows to a certain size and complexity it will be impossible for every developer to understand the same thing in the words you choose. That is why you should write a detailed documentation, perhaps use UML diagrams and, most importantly, meet in a team to discuss the work.
    No design paradigma can help you with this. Words of a human language are also just abstractions of real-world objects. What you say, and what I hear might very well be two different things.



    Quote Originally Posted by ischuldt View Post
    Shapes are just abstract concepts until they are put into the hands of something that can draw them.
    Why should it be a Screen? Its a completely arbitrary decision of yours that a Screen should be what draws them. It might just as well be a RenderingJob which knows what a Triangle is, and the Screen knows nothing about it.


    As I see it your Screen is my Graphics and RenderingManager class combined. But my RenderingJob is replaced by lists of Shape-Objects.
    To me, your approach seems less intuitive and flexible. You want to define beforehand what a RenderingJob is, and what it can do.
    For you, every RenderingJob is a series of Shapes to be drawn.
    In my approach it could be the same thing, but it could also be something completely different. I give the user the flexibility and freedom to do whatever they like in the renderYourself() method.
    A custom RenderingJob could be used to turn certain parts of itself on and off whenever needed. Or expand itself to visualize more data at once.



    On a sidenote: You should also read the definition of Object-Oriented Programming once more, because, again, what you call OOP and not OOP does not really correspond to any definition I know.

  21. #21
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by Cornix View Post
    Seeing as your Screen renders shapes, perhaps it is. But I would argue that "Screen" is a bad name for it. A screen is something on which you see something. A screen is passive, you observe it, but it doesnt do anything but show itself. A screen doesnt know shapes or rendering or anything.
    However, Graphics could be output to a screen. Perhaps its not the best word either, but it is what Swing uses and I just borrowed the term.
    Screen is more of a specific type of a RenderingDevice. Utimately you could derive whatever device you wanted off of that. Since in this case I'm interacting with a typical screen that's what I went with because that's what the spec says. By using a word like graphics your tying yourself to an implementation in this case the one that swing uses. If you decide in the long term you don't want to use swing to render graphic then it might not make sense.

    Quote Originally Posted by Cornix View Post
    You can never achieve that. Once your program grows to a certain size and complexity it will be impossible for every developer to understand the same thing in the words you choose. That is why you should write a detailed documentation, perhaps use UML diagrams and, most importantly, meet in a team to discuss the work.
    No design paradigma can help you with this. Words of a human language are also just abstractions of real-world objects. What you say, and what I hear might very well be two different things.
    No it's very achievable I assure you. Some people just don't like to try because it requires them to think differently. Younger developers are being trained to think this way from day one though and when you start out this way it's much simpler.

    Quote Originally Posted by Cornix View Post
    Why should it be a Screen? Its a completely arbitrary decision of yours that a Screen should be what draws them. It might just as well be a RenderingJob which knows what a Triangle is, and the Screen knows nothing about it.
    Again as I said a Screen could easily be derived from a RenderingDevice and so could whatever else you might use to render something. Screen is the word from the spec which is why I use it because in the specific use case that's what we're rendering to.

    Quote Originally Posted by Cornix View Post
    As I see it your Screen is my Graphics and RenderingManager class combined. But my RenderingJob is replaced by lists of Shape-Objects.
    To me, your approach seems less intuitive.
    That's only because of what is intuitive to you. As I said one of the goals of OOP is get people thinking in a way that is intuitive to everyone. Younger developers are being trained to think like me because the benefits of having us on the same page greatly outweigh any small perceived benefits you think your way has.

    Quote Originally Posted by Cornix View Post
    You want to define beforehand what a RenderingJob is, and what it can do.
    For you, every RenderingJob is a series of Shapes to be drawn.
    In my approach it could be the same thing, but it could also be something completely different. I give the user the flexibility and freedom to do whatever they like in the renderYourself() method.
    A custom RenderingJob could be used to turn certain parts of itself on and off whenever needed. Or expand itself to visualize more data at once.
    But you don't actually have the flexibility you think you have. Ultimately you're limited to what the screen can do. All a screen or any output device can truly do is display a series of images. What you call turning yourself off is really just displaying a blank image.

    Quote Originally Posted by Cornix View Post
    On a sidenote: You should also read the definition of Object-Oriented Programming once more, because, again, what you call OOP and not OOP does not really correspond to any definition I know.
    I think you're really the one that needs to take a deep look at what you're doing because your Objects are centered around what the do not what they are. A RenderingManager is not an actually thing. It's a concept you invented to perform a task for you. The same is true about RenderJob it's really just a thing you created to do a specific task for you i.e. tell the graphics to render themselves. And your graphics class well....graphics isn't a thing. A graphic is a thing. Your whole design is based on what you want to DO and you've invented things to do those things for you. An OOP design is based on what you have first, and then figure out how to do what you want with what you have.

  22. #22
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by ischuldt View Post
    Since in this case I'm interacting with a typical screen that's what I went with because that's what the spec says.
    That doesnt make any sense.
    A computer screen does not do the things you defined in your program. A computer screen does not know shapes. It has pixels and each pixel has a color, there are no shapes.
    So your choice of words is quite poor in my opinion.

    Quote Originally Posted by ischuldt View Post
    Again as I said a Screen could easily be derived from a RenderingDevice and so could whatever else you might use to render something. Screen is the word from the spec which is why I use it because in the specific use case that's what we're rendering to.
    It might be what you are rendering to, but it is not the thing that is actually doing any rendering. Its the target, not the worker.

    Quote Originally Posted by ischuldt View Post
    By using a word like graphics your tying yourself to an implementation in this case the one that swing uses. If you decide in the long term you don't want to use swing to render graphic then it might not make sense.
    I never said I want to use Swing. I just said I derived the word from Swing because it is already an established library. So where do you see me tie myself to any implementation? I


    Quote Originally Posted by ischuldt View Post
    No it's very achievable I assure you. Some people just don't like to try because it requires them to think differently. Younger developers are being trained to think this way from day one though and when you start out this way it's much simpler.
    Younger developers are being trained very different things. Any instructor will tell his/her students something different. Maybe its similar, but definitely not equal. What you believe in is a utopia, the reality is nothing like it.

    Quote Originally Posted by ischuldt View Post
    get people thinking in a way that is intuitive to everyone.
    Thats impossible.


    Quote Originally Posted by ischuldt View Post
    But you don't actually have the flexibility you think you have. Ultimately you're limited to what the screen can do. All a screen or any output device can truly do is display a series of images. What you call turning yourself off is really just displaying a blank image.
    Can you give me an example of a use case that would not be possible with my approach, but that is possible with yours?
    Because mine is very much more flexible. I can easily have my RenderingJob output to the screen and, simultaneously output to a file for debugging purposes. Or send its data over the internet to a remote client.



    Quote Originally Posted by ischuldt View Post
    I think you're really the one that needs to take a deep look at what you're doing because your Objects are centered around what the do not what they are. A RenderingManager is not an actually thing. It's a concept you invented to perform a task for you. The same is true about RenderJob it's really just a thing you created to do a specific task for you i.e. tell the graphics to render themselves. And your graphics class well....graphics isn't a thing. A graphic is a thing. Your whole design is based on what you want to DO and you've invented things to do those things for you. An OOP design is based on what you have first, and then figure out how to do what you want with what you have.
    You should back up your claims with a definition. As I said, you should read some definitions of OOP and quote them here, because what you say is vastly different from anything anybody else has ever said about this in my presence.
    For example, look at these definitions and you will see, that what I described is very much object-oriented:
    Object-oriented programming - Wikipedia, the free encyclopedia
    What is object-oriented programming (OOP)? - Definition from WhatIs.com
    What is Object-Oriented Programming? Webopedia

  23. #23
    Junior Member
    Join Date
    Sep 2014
    Posts
    11
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: functional programming with objects

    Quote Originally Posted by Cornix View Post
    That doesnt make any sense.
    A computer screen does not do the things you defined in your program. A computer screen does not know shapes. It has pixels and each pixel has a color, there are no shapes.
    So your choice of words is quite poor in my opinion.

    It might be what you are rendering to, but it is not the thing that is actually doing any rendering. Its the target, not the worker.
    These are just implementation details that can just as easily be hidden within the screen itself. Nobody needs to know these things in order to use it. What they care about is that you want to display an object to the screen. That's the English that was in the spec and that's what you should be going off of. Internal to the screen maybe you have a GraphicsCard object or whatever. Who cares. Your program should read like a story that anybody regardless of their programming knowledge should be able to read through and understand the basics of what's going on very quickly.

    Quote Originally Posted by Cornix View Post
    I never said I want to use Swing. I just said I derived the word from Swing because it is already an established library. So where do you see me tie myself to any implementation? I
    By using terminology that's specific to an implementation you make it harder to move to whatever implementation makes swing out dated.

    Quote Originally Posted by Cornix View Post
    Younger developers are being trained very different things. Any instructor will tell his/her students something different. Maybe its similar, but definitely not equal. What you believe in is a utopia, the reality is nothing like it.

    Thats impossible.
    Sorry, buy you're just flat out wrong. Why don't young people need to be taught how to use most websites and apps? Because a handful of similar design concepts are being used across pretty much all of them. When you get used to them on one site, they generally translate to the other.

    Quote Originally Posted by Cornix View Post
    Can you give me an example of a use case that would not be possible with my approach, but that is possible with yours?
    It's not about whether things are possible or impossible it's about how long would it take an average developer or an average joe for that matter to read your design vs mine and see what's going on. My design matches the exact English translation of the spec. If they can read English they can read my design and understand what's happening instantly. If they really need to know the internal details of how an object actually gets put on a screen they can read deeper. Most people don't care unless there's a problem with it that they need to fix.

    Quote Originally Posted by Cornix View Post
    Because mine is very much more flexible.
    No it really isn't. Best case scenario it's equally as flexible. You have spread out information about how to display things to a device across every single thing you want to display. Every time you obtain a new device you have to go out to all of your objects and teach them how to render themselves on that device. With mine all that information is contained within Screen so I only have to re-implement one object per device, mean while all Shapes can remain untouched and unchanged.

    Quote Originally Posted by Cornix View Post
    I can easily have my RenderingJob output to the screen and, simultaneously output to a file for debugging purposes. Or send its data over the internet to a remote client.
    So can I, but I only have to implement one new view for each. You have to do it across all your Shapes.

    Quote Originally Posted by Cornix View Post
    You should back up your claims with a definition. As I said, you should read some definitions of OOP and quote them here, because what you say is vastly different from anything anybody else has ever said about this in my presence.
    For example, look at these definitions and you will see, that what I described is very much object-oriented:
    These are just brief simplistic definitions. It would be like you quoting me a one or two sentence definition of Democracy. Even among so called Democracies there are those that are significantly more democratic than others. Your concept of OOP is just barely scraping by with the minimum requirements, but you're not really getting most of the major benefits of it because your thinking is still rooted in functional programming.

    To get you to fully understand it would probably take multiple college courses. I'm tired of trying and that's not what I was looking for when I started this thread anyway.

  24. #24
    Forum VIP
    Join Date
    Jul 2010
    Posts
    1,676
    Thanks
    25
    Thanked 329 Times in 305 Posts

    Default Re: functional programming with objects

    Why don't young people need to be taught how to use most websites and apps? Because a handful of similar design concepts are being used across pretty much all of them. When you get used to them on one site, they generally translate to the other.
    That's a poor analogy. No generalized project design exists. Companies do not even adhere 100% to Java's base coding standards. When companies or developers establish their project design and coding standards, they do so based on what works the best for their given project.

    My design matches the exact English translation of the spec. If they can read English they can read my design and understand what's happening instantly. If they really need to know the internal details of how an object actually gets put on a screen they can read deeper.
    You basically just described why JavaDocs exist. Realistically, most developers will not want to even look at your code, they will prefer to read your javadocs (unless they are fixing a bug, like you mentioned).

    Every time you obtain a new device you have to go out to all of your objects and teach them how to render themselves on that device. With mine all that information is contained within Screen so I only have to re-implement one object per device, mean while all Shapes can remain untouched and unchanged.
    You are looking at this the wrong way. It comes down to complexity. Not how difficult it is to read, the actual operational complexity. Many different classes which do small tasks will be FAR more flexible and maintainable than one enormous class which does everything. It is a bell curve, so there is such a thing as too much fragmentation, but there is also such a thing as too little.

    So can I, but I only have to implement one new view for each. You have to do it across all your Shapes.
    Does every Shape do it in the same way? If the answer is Yes, then you handle it once in the parent class. If the answer is no, then YOU need to implement it for each Shape too. Will you be doing it all in a single View? Yes. But that doesn't mean you aren't actually having to write the code for how you want each shape to behave.
    NOTE TO NEW PEOPLE LOOKING FOR HELP ON FORUM:

    When asking for help, please follow these guidelines to receive better and more prompt help:
    1. Put your code in Java Tags. To do this, put [highlight=java] before your code and [/highlight] after your code.
    2. Give full details of errors and provide us with as much information about the situation as possible.
    3. Give us an example of what the output should look like when done correctly.

    Join the Airline Management Simulation Game to manage your own airline against other users in a virtual recreation of the United States Airline Industry. For more details, visit: http://airlinegame.orgfree.com/

  25. #25
    Member
    Join Date
    Dec 2013
    Location
    Honolulu
    Posts
    83
    Thanks
    1
    Thanked 4 Times in 2 Posts

    Default Re: functional programming with objects

    That helps a lot. I was thinking of google search engine. And if I were to type in bear, the methods used are like objects, and the class files are also objects. The container would be the parent class and child class would be some other class using a get method or set method of obtaining some array of list of names. Like Bear.

Page 1 of 2 12 LastLast

Similar Threads

  1. Recurssion programming to retrieve inner values of objects
    By balajigoud in forum Member Introductions
    Replies: 1
    Last Post: June 22nd, 2013, 04:17 PM
  2. Having two functional "Rectangle" in same JFrame
    By Rdmy in forum What's Wrong With My Code?
    Replies: 1
    Last Post: April 21st, 2013, 12:13 PM
  3. [Question] Objects instantiated within objects.
    By Xerosigma in forum Object Oriented Programming
    Replies: 6
    Last Post: April 25th, 2012, 10:53 AM