Thread: 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?

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.

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.

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?

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

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.

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.

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

As a programmer I am not an artist.

You should try being both sometime.

Originally Posted by Cornix

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.

Originally Posted by ischuldt

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.

Originally Posted by ischuldt

Passing a Screen object into a RenderingJob is backwards.

I never said anything about that.

Originally Posted by ischuldt

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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

Originally Posted by aussiemcgr

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

Originally Posted by KevinWorkman

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.

Originally Posted by KevinWorkman

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

Originally Posted by aussiemcgr

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.

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.

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.

Originally Posted by ischuldt

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.

Originally Posted by ischuldt

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?

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by ischuldt

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.

Originally Posted by ischuldt

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.

Originally Posted by ischuldt

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by ischuldt

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.

Originally Posted by ischuldt

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.

Originally Posted by ischuldt

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

Originally Posted by ischuldt

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.

Originally Posted by ischuldt

get people thinking in a way that is intuitive to everyone.

Thats impossible.

Originally Posted by ischuldt

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.

Originally Posted by ischuldt

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

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

Originally Posted by Cornix

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.

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.