1

I'm working on a winforms project that involves 3d models, Opengl graphics, hierarchical project files and uses an MVP approach. Currently i have things setup such that when the user manipulates objects the view is updated using events triggered by the object. For each object that is added to the hierarchy in e.g. a list, i need to add handlers (since i do not have a variable assigned to the object, which could be declared withevents). When storing (serializing) this hierarchy the handlers are not included. So when a project file is opened these handlers need to be setup again, or nothing works anymore. This is cumbersome and i am considering either :

  • removing all methods and functions from the respective classes to libraries, so that in the end only data is stored in the hierarchy, and avoiding the use of internal events all together. or
  • moving all methods, functions and events into inheritable classes that are not serialized

Since this project has reached a certain 'critical mass' and my limited experience does not allow me to see past my design choices, I am starting to become reluctant to change the setup again and again. So I am wondering if someone with some experience on larger projects can give me some advice ? or perhaps tell me if this approach is going to cause problems in the long run, or better yet give some pointers on handling these issues. In any case, all help is welcome.

Update :

Hi, Thanks for taking the time to answer the question. Based on the input I recieved below I started to read up on topics like Data tranfer objects DTO, Data value or access objects, Domain objects, Business layer, Persistence layer/Data layer and the works. Unfortunately most examples deal with databases and tables, which is not very fitting for 3d worlds, but the essence is now clear to me.

In effect I have now created a data-only representation of my project hierarchy which holds all the data and can be serialized easily. All data objects are plugged into domain objects which add functionality to manipulate the data and provide behavior (i.e. events and handlers). Herein all setters and getters point to the variables in the data object The domain objects also form a hierarchy, similar to that of the data layer. To avoid maintaining lists of handlers, i've hard wired the events for a single object and only change the reference to the one which is active/being manipulated/needs updating etc.

Thus now I have a Model View (passive)Presenter + Data/persistence layer arrangement, which will do what I need. Thanks for the input.

Best PeteByte

Improve this question

1 Answer 1

Reset to default
3

I would segregate the persistent data to DTO's that are consumed and produced by full blown long lived objects that were taught what handlers existed were when they were constructed.

Done this way you don't have to create hierarchies or libraries. Persistent data comes and goes. The objects that know how to deal with that data send messages to other objects telling them what they need done.

Each long lived object should be no more complex than is needed to handle a single idea.

I've used this pattern successfully many times. My favorite was a chess AI me and my teammate created (that, incidentally, won the tournament). Each kind of game piece had one object. Even though there are 16 pawns on the board I had only one pawn object. And it didn't know where it was on the board until you told it. I stored many references to it on the board. It's only job was to figure out what it's legal moves were.

I know this flies in the face of the style of "modeling the world as objects" but I've found true object oriented programing isn't done that way at all. Sometimes I create objects for things that don't even exist in the real world.

Don't be afraid to write code driven by your needs rather than some prescribed style. Most people giving you advice have no idea what you're up to.

Improve this answer
3
  • @PeteByte - In particular, since this sounds like a 3D editor of some sort, you can create manipulator objects (in advance or on the fly) and dynamically plug in the selected scene object (or associate the two in some other way), based on the currently selected tool, then process manipulator events. Many manipulations can be generalized. Also, since you probably have some sort of rendering loop in there, you may forgo .Net events and rely on some sort of an event queue (you don't have to process events immediately, just within the update).
    – Filip Milovanović
    Commented Oct 29, 2019 at 4:10
  • 1
    @candied_orange, although I agree with what you say, I think your wording implies a bad basis you are distancing yourself from - OO does support the idea of having 'objects' that don't map to real world objects, otherwise you must have read a poor book. And sticking with 'prescribed styles' is not usually given as advice - only by dilettantes - it is quite normal to consider them 'helpful hints' that you are free to ignore. You are supposed to understand the advantages of styles, so you know when they are useful, and when not, they are a toolbox that is good to know, nothing more.
    – Aganju
    Commented Oct 29, 2019 at 10:27
  • @Aganju Dilettantes indeed. Unfortunately my first exposure to OOP was from such people. Still getting over it. My sense is that the "polymorphic messages" form of OOP is still becoming dominant over the "everything's a hierarchy of things" understanding of OOP.
    – candied_orange
    Commented Oct 29, 2019 at 10:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.