Contents tagged with Commerce Server
-
Object Oriented Programming Refresher
Recently I was challenged by a colleague who asked some very basic questions relating to object orient programming. I know these concepts very well, but sometimes you have to stop and think twice about them, especially if most often than not, you do not implement these concepts in your day to day programming activities. As developers, we often find ourselves in situations where the need to get things out the door and into production tend to encourage us to not think about doing things the right way, but instead, getting the work done in the least possible time. Object Oriented concepts are something every serious developer should know inside out. Sure you can get by without practicing it, but that approach might come back to haunt you down the road.
Classes are the foundation of Object Oriented Programming. Business Logic code should be seperated into groups of related classes that satisfy a business need. There should be a clear seperation of concerns. When planning a development strategy for our applications, we should at all times try to envision our applications as being seperated into three logical tiers. Strictly speaking, having three logical tiers doesnt dictate that our apps must to be deployed physically as a three tier app...all the tiers could live on one one physical machine, or they could be deployed accross three different machines. They could also be deployed on multiple machines in the enterprise, in what is known as an n-tier architecture. Our apps will perform much better when we distribute the processing requirements accross multiple machines...business logic components run on machine A, Data Access components run seperate machine, and the front end logic running on a clinet pc or web server somewhere else. Microsft Transaction Server, and now Enterpise Services can act as a broker for our components living in the data access and business logic tiers, and offer such services as transactions support, object pooling, which promotes better scaling applications.
So, what is an abstract class. What is a sealed class. What is the difference accessibility methods out there that I can apply to my classes and methods, and why do I need them? What are interfaces? when is it useful to use an interface? These are the questions that rolled through my head when I was first introduced to OOP years ago. Over time, as you develop more business level applications, the importance of these concepts become clearer.
Inheritance is a pupular term among the OOP purists. So what is Inheritance, and how does it relate to OOP? Perhaps the best way to describe this would be to imagine a hypothetical situation where you are building an app that requires you to Mainatin a list of employee records. All employees must have an employeeID, they must have a first name, and they must have a departmentID etc. In addition, there are some employees that work on a part-time basis, and some that work full-time.
Looking at the above scenario, we have indentified the need for an employee class to service our application. but before we start building our employee class, we need to take a closer look at how that class will be implemented. There are common features that all employees have, but there are also some features that are specific to the full-time employee and others that are specific to the part-time employee. For instance, when we calculate the monthly pay for the full-time employee, the logic might be different from what we do when we calculate the salary of the guy that is employed part-time. It might help if we define a baseline Employee class that contain the common functionality, properties etc, and then further extend these classes in other derived classes to inplement the specific functionality. So at the root, we might create an employee class, and two derived classes: FullTimeEmployee and ParttimeEmployee. Both these classes will be based on the base Employee class and will inherit any functionality exposed, but will further provide indiviual methods that will be used to calculate an employee's salary.
By marking our employee class as Abstract, we are marking it as a class that cannot be instantiated directly...we are saying that this class exists only to be further refined through inheritance. The exact opposite scenario to that would be to mark our class as sealed, which would mean it cannot be further refined through inheritance.