I think your style is really nice. What you want to accomplish is the possibility to reuse code and to Never need to duplicate code. So if you have two different types with duplicate methods try to derivate them from the same type, and let them inherit that method. In that way you can change the method for both these types if you ever want to change it. Also consider implementing vectors and deltatime. A tip if you want to change something, like an update method in point, is that you could copy and rem the current method. In which you have the backup if the new way don't work as planned. And even if you can make things very Abstract with OOP try not to. Most times you can make the code more intuitive; more self explanatory. Even if the code is trival add a comment on what the method or type is supposed to do. It's worth it!
I would have a Create or Spawn function in the point entity, which would allow you to create points for example on one line: Point.Create( X, Y ).
You can have the initiation stuff in a Initiate() or Start() method in Application. Including the stuff required to exit the application. TApplication.Update()
TApplication.CleanUp(). I see no wrong in having the application stuff separated, perhaps even in a separate file. You are not very likely to change that code that often anyway. And if you would like to change that part, copy the whole file.
__________________________________________________________________________________________________
Extra Note: Actually I'm right now working with a new OOP approach. It's crazy as hell but I can also reuse or change ANY part of my code independently. I'm yet to see if the system will work in bigger projects. I got the idea from this article: Object-Oriented Game Design - A modular and logical method of designing games . I'm not saying that it is the perfect way to do it! I'm myself trying it out in a smaller implantation to see how it scope. I'm only following the article to 20%. The overall idea is that methods and fields in your types could be types. Any action requires a set of states. If an entity have these states they can use the action. In this way you can design actions ( ex:AI ) totally independent from the game. Because every game do have similarities a lot of code can be reused all the time, even inside the same game! It's still an experimental approach, interesting read but NOT a complete OOP technique that works.
I would have a Create or Spawn function in the point entity, which would allow you to create points for example on one line: Point.Create( X, Y ).
You can have the initiation stuff in a Initiate() or Start() method in Application. Including the stuff required to exit the application. TApplication.Update()
TApplication.CleanUp(). I see no wrong in having the application stuff separated, perhaps even in a separate file. You are not very likely to change that code that often anyway. And if you would like to change that part, copy the whole file.
__________________________________________________________________________________________________
Extra Note: Actually I'm right now working with a new OOP approach. It's crazy as hell but I can also reuse or change ANY part of my code independently. I'm yet to see if the system will work in bigger projects. I got the idea from this article: Object-Oriented Game Design - A modular and logical method of designing games . I'm not saying that it is the perfect way to do it! I'm myself trying it out in a smaller implantation to see how it scope. I'm only following the article to 20%. The overall idea is that methods and fields in your types could be types. Any action requires a set of states. If an entity have these states they can use the action. In this way you can design actions ( ex:AI ) totally independent from the game. Because every game do have similarities a lot of code can be reused all the time, even inside the same game! It's still an experimental approach, interesting read but NOT a complete OOP technique that works.