OOP in NAV

Fommo · 2007-10-11

Hi

I'm trying to make NAV a little object oriented. I have made a CodeUnit representing a main message and a bunch of other Codeunits representing some specific submessages.
In the main message I can hold up to X submessages of each type.
It works pretty well.

BUT, a thing that would be really awesome is if I can get some more generalisation or polymorphism here. =P~
So, is there anyone who knows if I can do an array of variants representing the submessages and then call some common functions for all the submessage objects? Is it even possible to do some conversion back to codeunit when the message is stored in the variant. Is it possible to test which codeunit that fits in the stored variant?
I know there is a ISCODEUNIT, but it's obviously not enough. :-k

matttrax · 2007-10-11

Navision is not an object oriented system and isn't really designed to be. Coming from a college background where 90% of the focus is on OOP it was a little weird for me too, but you kind of just accept it.

So far I haven't run into anything I couldn't program in Navision, so I don't see the need for it. Why do you need to program your mod this way? Or are you just doing it for fun?

Yaroslav_Gaponov · 2007-10-11

Hi

In NAV you can export and import objects via files - well-known opportunity.

1. export to file
obj.RESET;
obj.SETRANGE(ID,55550);
obj.SETRANGE(Type,obj.Type::Codeunit);
IF obj.FIND('-') THEN BEGIN
obj.CALCFIELDS(obj."BLOB Reference");
obj."BLOB Reference".EXPORT('c:\a.obj');
END;

2. import from file
obj.RESET;
obj.SETRANGE(ID,55550);
obj.SETRANGE(Type,obj.Type::Codeunit);
IF obj.FIND('-') THEN BEGIN
obj."BLOB Reference".IMPORT('c:\a.obj');
obj.modify;
end;

You could be save and load dynamics you objects for execute some parent's functions for example...

jlandeen · 2007-10-11

I have to agree with matttrax here, Navision really is not well suited to true Object Oriented Programming. It does allow you to develop applications and business functionality very quickly. The new tools & capabilities in 5.0 give you a lot more power then have been available in the past.

I find the cloest way to represent OOP in Navision is to build table structures that closely represent objects and place as much code in the tables as possible that works with the data. This ensures that Code (methods) & Data (properties) are at least compiled into the same object. It's not idea...and in oder to copy or inherit from objects you have to copy one object into the other (basically copy & fork).

Also remember if you wanted to you can build your own recordsets and objects in memory using RecordRef objects and Temporary Tables.

kine · 2007-10-11

Yes, OOP is good for teaching on University, but not needed in real life. Everything what you want can be programmed without OOP (look at whole Linux, no OOP there ;-)). OOP is good for modeling. But the overhead is big. NAV is focused for fast developing - it is why some parts of OOP are used (encapsulation - methods, properties...). But the part which is not needed (generalization) is not there. First dynamic thing in NAV were RecordRefs and it was big step forward. Now we just needs to be able to run FORM for RecordRef and everything will be easier. Today it is not possible (e.g. to run Lookup table for RecordRef without long list of forms for each table).

If you need OOP, you can program it in VC and use Automation to use it in NAV... 8)

DenSter · 2007-10-11

OOP is a means to an end, not the end itself. The NAV IDE as it is today is not object oriented, and there is nothing you can do to make it that way.

jlandeen · 2007-10-11

I agree that OOP is a nice general idea to strive towards, but Navision must be grouned in the real world and be applicable to business. I've found that with .Net and other truly Object Oriented languages you really struggle to build functionality as quickly as you can in Navision.

I think Navsision is not OOP because it requires there is a common platform and executable base that places restrictions on what and how you can build your customizations. I've seen similar fully object oriented frameworks (like JBoss and some build on .Net) that require a lot of configuration and development time just to get simple things working.

As denster pointed out...OOP is a means to an end. In most cases clients care more about getting business functionality codified and running (within budget) then they do about the specifics like an OOP development environment.

Waldo · 2007-10-12

Before my NAV carreer started, I was an OOP-addict. Really. The step to NAV was quite challenging those days ... . Didn't like the environment, didn't like the fact that it wasn't OO, ... .

If you say, OO is not needed, I agree. You can do whatever you like with non-OO environments. If you say, it's only for design, I agree. But if you put those two together: if you have to create an (big) application, it's much easier when you have an OO overview of the system, to put it into OO code. (Long live UML!

)

But, NAV is an existing application. Microsoft has to maintain simplicity and easy (read: fast) development. This is something OOP doesn't allow. Changing the design usually affects multiple layers in the class design, which you do not want. Therefore, we should be glad the system isn't OO-based! And let's hope MS keeps it this way

.

... to give my two cents ... (or how do you say it ...)

Yaroslav_Gaponov · 2007-10-12

Hi

Enough of the grumble

Any idea have a right to live. All your facts are known long ago.
So have you a propose?

idiot · 2007-10-12

but... but... Navision is a big application, an ERP system...
and...and.. ERP systems are not meant to be simple
also Microsoft bought it over, they didn't develop it...

Waldo · 2007-10-12

If you compare AX development with NAV development ... really ... you'll agree

petevans · 2009-12-11

Would be nice to be able to make generic functions though.

I am making a "PrintToPDF" function now, and have been trying to make it work with any report, so I have experimented abit with using "Object" for polymorphism, but no luck so far.

Guess I'll need to make it a "CustomerToPDF" function instead.

OOP-mindset really sticks from school! Hard to let it go.

Waldo · 2009-12-11

that's a coincidence, but I gave that exact same feedback to Microsoft not too long ago

OOP in NAV

Comments

Categories