Object-Oriented Objectivism

A whole collection of blogs have made their statements against Object-Oriented programming.

I say one thing to all of you: It's all about who you are. In my opinion, developers, more than anyone else, reflect their personalities in their work. For example, I'm a very visual person; I always, always, always build my interface first. Now of course like any well designed software it changes over time, but for me, having an interface to go by reminds me of what the goal is--user satisfaction. Which is why I'm so addicted to OO:

Users, no matter how tech-savvy, think in nouns and verbs: "I click the button, I get a report.", "My document must be saved." Even developers, despite their own development practices, if they use an IDE, write code with objects in mind: "I submit a build, which has bugs, that are fixed."

Why should this not be reflected in our code? I was recently tasked with the creation of a simple utility for "admin" users to submit Software Development/Change Requests:

public partial class frmSubmit : WinForms.Form
{
SDCR thisSDCR;

public frmSubmit()
{
InitializeComponent();

thisSDCR = new SDCR(SubmitSDCR.Properties.Settings.Default.Server, Properties.Settings.Default.Database);

lblRequestNo.Text = thisSDCR.RequestNo.ToString();
FillReasonList();

if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
this.Text += " v" + System.Deployment.Application.ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString();

#if DEBUG
txtRequestor.Text = "Test";
pthExecPath.Text = @"\\mfgvolumes\GDrive\SOFTWARE\ClickOnce\Install\SubmitSDCR\SDCR_Rev 2.xls";
txtRequestDesc.Text = "Request";
lstReasons.SelectedIndices.Add(0);
lstReasons.SelectedIndices.Add(3);
#endif
this.ActiveControl = txtRequestor;
}

private void ClickSubmit(object sender, EventArgs e)
{
if (!ValidateInput()) return;
Submit();
Print();
DisplayInfoBox("Sumitted SDCR", "Your SDCR has been submitted!\n\rCheck your printer for a hard copy for your records.");
ExitApplication(this, new EventArgs());
}

private void FillReasonList()
{
foreach (ChangeReason c in ReasonCollection.GetPossible(SubmitSDCR.Properties.Settings.Default.Server, Properties.Settings.Default.Database))
{
lstReasons.Items.Add(c);
}
}
private void Submit()
{
thisSDCR.EmergencyRequest = chkEmergency.Checked;
thisSDCR.InScope = chkInScope.Checked;
thisSDCR.Requestor = txtRequestor.Text;
thisSDCR.RequestDate = dtpRequestDate.Value;
thisSDCR.ExecutablePath = pthExecPath.Text;
thisSDCR.DescOfRequest = txtRequestDesc.Text;
thisSDCR.DescOfReason = chkOther.Checked ? txtReasonDesc.Text : string.Empty;
int length = lstReasons.SelectedItems.Count;
for (int i = 0; i < valid =" true;" valid =" false;" valid =" false;" valid =" false;"> 0) return true;
if (lstReasons.SelectedItems.Count > 0) return true;
Globals.DisplayInfoBox("Invalid Input", "You must select aReason for Change, or specify a reason in the Description box. Check the form and try again.");
return false;
}

private void chkOther_CheckedChanged(object sender, EventArgs e)
{
txtReasonDesc.Enabled = chkOther.Checked;
lstReasons.Enabled = !chkOther.Checked;
if (!chkOther.Checked)
{
txtReasonDesc.Clear();
this.ActiveControl = lstReasons;
}
else
this.ActiveControl = txtReasonDesc;
}
private void DisableReasonList(object sender, EventArgs e)
{
if (!lstReasons.Enabled)
lstReasons.SelectedIndex = -1;
}
private void ExitApplication(object sender, EventArgs e)
{
this.Close();
}
}

To me, as long as the underlying objects work, and return the data I expect, I could care less about how nested the inheritance hierarchy is. So SDCR inherits DataAccessObject, which inherits DataConnectionObject, which contains a Dataset, which contains a DataTableCollection, which contains a DataTable, which contains a DataRowCollection, which contains a DataRow, which contains an array of objects, which is where my Request Number is stored.
I could either create my own implementation of all of this every time I write a new app, or I could just build an object called SDCR, set it's RequestNo, Name, and Date property can call it's Submit() method, and be done with it.

To me, OO = Reusable. A DLL full of useful common functions is one thing, an object full of ready-made access to a database with a simple "new SDCR("bob","change").Submit()" is a whole other world of usefulness.