Yep, and that is the way I tend to code applications in HLASM or other assembler languages as well. That methodology doesn’t set well with everyone though, as it is “not efficient” or “wastes code” or “but why would I go to the trouble?” And of course, HLASM doesn’t enforce this practice, even if you use some of the structured macros. :) I assume you also tend to use concepts like Data Typing where appropriate, and so on. These are all very good “best practices” in my opinion - practices of which I heartily approve of course.
In fact, I contend that OOD (Object Oriented Development) is nothing less than a codification of all these kinds of best practices that programmers and engineers have learned and built up over the years. Given that, of course OOD applies to almost any possible project and can be applied to any implementation. OOP (Object Oriented Programming) however, is a much more specific instance, and is concerned much more with implementation than design. It is subject to endless arguments, stirs up religious fervor among the adherents of it’s various sects, and oftimes - a practice that just gets in the way of doing the job. It’s a lot like Agile development that way. And whatever you do, unless you want a really heated debate, don’t tell that to an Agile/SCRUM evangelist! :) -Paul > On Feb 7, 2018, at 9:44 AM, Gary Weinhold <weinh...@dkl.com> wrote: > > Paul wrote (snipped): > > Please consider, HLASM is a fantastic platform for writing Bottom Up Design > programs. It is fun to hack away in the weeds and see a really cool result > pop out. > > > It's also a fantastic language for writing top down design programs. I've > started many projects by writing all the modules and routines within the > modules with calls or BAS (now JAS) to meaningful labels, localized comments > for what would be done in the routines, perhaps a simple WTO to prove it got > there and a BR to return. Then I started coding from the top down, adding > temporary code in lower levels where needed to return constant values so the > design could be verified before I even considered what coding techniques I > would use in the lower level routines. > > Gary > > > > > Gary Weinhold > Senior Application Architect > > DATAKINETICS | Data Performance & Optimization > > Phone: +1.613.523.5500 x216<tel:+1.613.523.5500%20x216> > Email: weinh...@dkl.com<mailto:weinh...@dkl.com> > > [http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]<http://www.dkl.com/> > > Visit us online at www.DKL.com<http://www.dkl.com/> > > [http://www.dkl.com/wp-content/uploads/2015/08/banner.png]<http://www.dkl.com/mailsig> > > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, you > are not authorized to use or disclose this information, and we request that > you notify us by reply mail or telephone and delete the original message from > your mail system.
