Technology has evolved from a niche field to integral to the business process, from the corporate data center to the desktop programmer at a small business. Software development tools such as Open Source frameworks and Microsoft's Visual Studio have brought technology to a level that anyone with interest can deploy sophisticated applications. There is still much work ahead necessary to bring it all together to create an efficient streamlined business environment which also ties into the economy overall.
Agile programming practices have been hyped recently, and that might not be solely due to their effectiveness, but their relevance to business development. Agile programming is similar to the Lean Six Sigma process that identifies problems in value stream and works to continuously improve, sharpen, production processes.
It was not long ago that Object Oriented programming was considered new, but now it is essential in any programming environment that seriously wants to extend the life and effectiveness of its applications. The alternative, Procedural programming, is the path of least resistance when a developer wants to just dive in and make a program work. But that leads to problems down the line when linear logic needs to be resolved. The linear logic required for procedural programming will almost always change in years ahead, and that might require a system to be completely rewritten whereas OOP systems consist of extensible objects which can be easily modified and extended.
Bringing it All Together
It is clear that with each passing year we will see new computers, portable devices, phones, and technology we have not even seen that depend on software. Software does not write itself (yet); rather, it depends on professionals to realize the fundamental philosophies of both programming architecture and business concepts. Design concepts in programming have reached a state where the beauty in logic of OOP related concepts supersede the language itself, allowing programming aptitude to retain relevance beyond the life of any one language.
The information economy is a serious turning point in the economy and with it businesses are required to understand how finances flow through divergent creative systems and their related products that people are willing to buy. The same concepts used to create business applications are relevant to business, and as time goes on the architects if the systems used to create software will, by virtue of their job requirements, tie together even more, the development process with business needs.
- Purpose of Object Oriented Methodology in Business
- Tricks in SSRS and Analysis Services
- SQL Error: UpdateCommand is not supported
- Fixing Duplicate Songs in Windows 8 Phone
- Pay Raise Retirement Calculator
- Centering/Distributing Multiple DIVs using JQuery
- Thesis: Using Conjoint Analysis to Elicit Preferences for Instructional Media
Tuesday, May 7, 2013
Wednesday, March 3, 2010
OLAP Cubes in SQL Server
SharePoint and SSRS Reporting Services
Buy Woodstock - eCommerce website
Conjoint Analysis - Statistics Helper
Web Upload - Printing Solutions
2020 Recycling - eCommerce Site
And Many Others.
If you need to make a payment for a website I have created, or need to reserve work, please use the PayPal button below:
Posted by Dave at 9:35 AM
Wednesday, February 3, 2010
Friday, January 22, 2010
I have found many explanations of how OOP works, but few delve deeply into the purpose of each individual component. Personally, I like to know purposes. I've created dozens of applications which work perfectly fine without using many of the objects that are available. I imagine others have too. Still, programmers tend to look at how things work, rather than why they were designed to work that way, so I thought I'd write my own folksy explanation of the most common, yet optional, objects. (I currently use C# but these concepts tend to be universal.) So why do all these objects exist? There are 3 reasons I can think of:
1 - The main reason OOP exists, in my opinion, is because it promotes structuring teams of programmers and separating their work in a way that the technical supervisor can better understand. By providing such clarity to supervisors, the business can more quickly adjust its workflow to accommodate their objectives.
2 - Linear logic often works fine the first time through a project, but coming back to code after requirements change, the initial linear logic might be broken, so one might find that it would have been easier to modify the behavior of objects. OOP is so profoundly different than linear code, that writing spaghetti code would be nearly impossible; however, it is debatable whether readability of OOP is better or worse since the logic is no longer visible all at once. What is the point of avoiding spaghetti code if, even in simple projects, the logic is no longer readable? I'm not sure.
3 - In rare cases, OOP might be the only reasonable approach. Multiple objects might need to exist in a way that they all have frequently changing states. Say you are making a video game and you have dozens of spaceships flying around that all have their own AI, and they have the ability to spawn child crafts. In that case, they might be better off handled as objects rather than referenced from an array or a list.
Interfaces are in a separate section that will implement methods in a class. They do not need to expose all of the class methods, only the ones that will be used by others and yourself. You might not want others to see all your methods. You might not want to see all your methods yourself. By looking at your interface, you can see only the methods that matter.
Assembly is a fancy word to describe a "unit of deployment", and "unit of deployment" is a fancy phrase that means a project, in the case of C#, which is compiled into an .exe or .dll when deployed. But that's stating what it is, without stating its purpose. In business, this depends on the framework, so in regard to .Net which can have only one language per project, I'd say its most relevant purpose is to group people together who are proficient at the particular language.
Attributes are specific to .Net, and they appear to be metadata placed in square brackets before classes and methods. They break the rules of typical OOP interaction and allow code to communicate with other parts of a project, such as telling a View in MVC that a text field should be displayed as required. As with everything else in the world, Attributes are not necessary in order to write code, but they provide a more readable element to what is otherwise usually indecipherable.
Classes are the fundamental building block of all object oriented languages (C++, Java, C#, Ruby, etc), which also happen to allow for the use of linear logic. Meanwhile, the use of abstract classes are the mark of a true OOP programmer. It would be difficult to use abstract classes without truly understanding OOP in all its glory. Abstract classes are similar to interfaces but provide all the power of code, enabling inheritance and reuse of code by making it possible to override classes.
Access modifiers control access to methods in various parts of an assembly. More creative individuals might name all of their methods in a very distinct manner in order to avoid having multiple OrderTotal methods, for example. However, if there are multiple methods with the same name, and they are all publicly accessible, that can cause confusion. Access modifiers (public, protected, internal, private) allow the programmer access to methods only where they are meant to be used, eliminating the possibility of error.
Properties and Accessors
I'm combining Properties with Accessors, since they are used in conjunction with one another. Properties are created inside classes in order to retain data that applications need to compute. They can be avoided by linear programmers who simply pass data into and out of methods. Using Properties is intuitively cleaner than allowing data to float randomly inside an application where is could get lost or mismanaged; however, the programmer must deal with the slight overhead of creating an object and then knowing what to do with it. Properties are similar to regular methods except they have 'get' and 'set' Accessors designed to allow class objects to assign and retrieve data.
A namespace is to computer programming what a file folder is to file storage on your hard drive. Saying anything more would just add unnecessary confusion. They are optional, yet appear by default in projects in order to provide a place to store objects. Projects most often will need more than one conceptual unit, which is wordier than saying 'namespace'.
More to come...
Posted by Dave at 10:53 AM
Wednesday, December 30, 2009
If you ever wanted to display a book on your website or blog, here is a little animated book that looks pretty cool. Cushing Company in Chicago is working on a way you can upload pages of a book and effortlessly send them to your sites like the one below. As you can see, you can use the mouse to flip the pages of the book below:
Posted by Dave at 11:44 AM