There's a reason the best players at the highest level of sport turn up at Training Camps to practice fundamentals. It works. These days they don't show up to get into shape. Today, they arrive in shape, because someone wants their roster spot. They still practice funDAmentals. Computer software isn't any different, but you don't have to sweat much to practice and perform.
OOP is Not an AutoCAD Command
"Model based" software is constructed on Object Oriented Programming theory and practical methodology.
Object Oriented Programming or “OOP” is an evolving conceptual model of programming development. The term is actually used pretty loosely in the popular technical press, and even among programmers themselves. The basic concepts of OOP are simple and reasonable. How these concepts are implemented or accomplished in the actual software is another thing entirely. Almost every popular software development environment currently in use is OOP. Anyone who develops on top of any Windows operating systems employs OOP.
OOP is a “structured” programming methodology. Structured means that there are rules that define how you do things and how they are implemented. Most of this has to do with how objects are built and how they interact with other objects. The theoretical goal is to have a programmer’s object be able to interact with another programmer’s object and produce an expected result.
An object is a “black box” device - you put in things and the black box produces predictable results. What goes on “inside” the object is up to the programmer. How the object responds to events is up to the programmer. The parts of the object and interactions that the programmer chooses to make public (useable by other objects) must conform to the defined and structured rules.
What is an Object in OOP?
Objects in OOP have essentially three distinct pieces serving three different purposes:
o Properties - formally called the Properties Collection
Properties define the particulars of the object. Properties can be inherited from another object.
o Events – all objects in OOP are event driven.
Some event must occur for the object to trigger processing of the properties collection and other code built into the object.
o Methods - produce the output of the object - the predictable results
Probably the MOST IMPORTANT fact about an object is that it is SELF-CONTAINED. In older versions of AutoCAD, the program’s single executable drew all the lines, arc, and text. Current AutoCAD objects tell the software what they “look” like. Welcome to the world of the Display System. The substance or value (the beef) in an OOP application is contained mostly in its objects and the interface that allows you to affect them.
What lessons can we learn and apply in our daily work from OOP?
OOP tells us Where and What to Check When Things Go Wrong
You are most likely to feed the beast the wrong food.
You input something incorrectly into the object's Property Collection. That can be easy to identify and fix for a primitive object like a LINE. We are CAD skilled at that.
For many Civil 3D Features, things are more complicated. The trick here is that Properties can be inherited, and the obvious isn't obvious at all. Where is that Property hidden away? Feature Line Priority is a good example of this. If you understand the reason for the Site Parcel the location makes sense.
Civil 3D Features are not single objects. Don't ever think of them like one. They are all multiple object collectors. In OOP speak, that's what a "Feature" is. The more complex Features in the Toolspace, like Corridors, are "nothing more" than Collectors of other Features.
The idea of a Collector might seem weird at first, but anyone who's used a Land Desktop and created and maintained a surface can easily get this. An LDT surface is nothing more the a collector of different kinds of data. A surface model is the result of the processed "data properties" of a lot of things. It's a world where substance and order matters. A crossing breakline anyone?
Study the Properties of the Features
What the Civil 3D Feature collects is important to know. Then you know where to look for the bad properties. The interface is pretty consistent so usually fixing the Property isn't so bad once you know.
OOP is Like Gravity
Whether you like it or not OOP uses Noun/Verb syntax (Select>>Move). OOP always deals with properties in piles. If you keep the LDT/ACAD mindset of "Move>>That little piece" the model-based software will fight you tooth and nail.
Remember Civil 3D handles all the little pieces better than you can. If you constantly find yourself wanting to take all the little pieces back, you're probably missing some important information about the Feature.
Model-based software's big advantage and reason for existence is collecting up all the details into tidy little manageable packets after all. For example, Civil 3D produces annotation from the model and publishes them via Label Styles. Got the right Styles no problem. If you never use Dragged State, you win. You either get it or fight it.
Event Powered Order
The next way we mess up is doing things in the wrong order. OOP Events from objects drive the software. Again we have to think and act consistently Noun/Verb. Next where and how you select the feature can make all the difference. Remember that selection is an Event and something IS going to happen when you do it.
All these object interactions driven by the Events take time to happen even with the latest hardware and the best code.
One of the most common errors we physically make is doing too many things too fast. Errant mouse clicks are not your friend.
Manage to Control
You can and should Manage and Control the "dynamic model". You don't want Features rebuilding before you have the Properties set up correctly. You don't have to have everything turned on in fine detail all the time. Good Style collections help you there.
As people we do the unexpected. We also do them in places the programmers never expected. But before we blame things on the bugs and the perverse nature of inanimate objects, let's get our fundamentals in shape.