Programming Forums > Application Development > Other Programming Languages

Darkhack · Feb 15th, 2006, 1:21 AM

You'll probebly see me making a million threads like this, lol. I love talking theory. I dont have a lot of expierence with seeing other peoples code so I don't know how things are done by others. Anyways, I was wondering if this theory is acceptable to most programmers. Is it good/bad practice to create all of your objects and then allow them to be used by every other object? I know that sounds confusing. Look below for an example... As you can see I define my objects in advanced and then inherit all of my classes on the main one. That way I can call all of my objects from inside the objects themselves. I actually found this to be pretty easy in some cases. Although I question whether it is acceptable among other programmers. Although this is good in theory, it may prove a little difficult to manipulate it if you had more than instance of a class because of the issues involving which object to manipulate, but if you are careful, I am sure you could work around it. Although if you are only using one instance of a class, it certainly saves you the time of having to pass the objects as parameters and then return them.

(Toggle Plain Text)

// MAIN
public class MainClass
{
	public SubClass obj1;
	public AnotherClass obj2;

	public static void Main()
	{
		obj1 = new Subclass();
		obj2 = new AnotherClass();
		
		obj1.Display();  // <-- basically the same as obj2.Output();
	}
}

(Toggle Plain Text)

// SubClass + AnotherClass
public class SubClass : MainClass
{
	 public void Display()
	 {
		 obj2.Output();
	 }
}

public class AnotherClass : MainClass
{
	public void Output()
	{
		Console.WriteLine("I'm AnotherClass being called from SubClass!!!");
	}
}

grumpy · Feb 15th, 2006, 1:48 AM

What you're doing is essentially making everything have a common base class. A side effect of that is that it is very easy to accidentally introduce coupling you don't want between your classes. The more serious one is that it introduces a phenomenon known as the fragile base class which is a maintenance nightmare in large programs: among other things, it eliminates any potential for separate compilation as (if one thing changes) it is almost certainly necessary to rebuild everything.

Do it with a moderate size project (eg a few hundred or a few thousand classes) and you will find you have build times, even when you make minor changes to a line or two, that are quite long. You will also find that is is more difficult to understand how your program works, which makes it difficult to work out where to introduce a new function if you need to.

Arevos · Feb 15th, 2006, 5:25 AM

Grumpy's quite correct. I'll also mention that Singletons come in useful when you absolutely need to only have one instance of a class.

Darkhack · Feb 16th, 2006, 6:43 AM

How about treating class as "steps"? You build a framework to use and once that is complete the actual action of the program is completed in steps on higher level classes. Once an object is done doing what it was designed to do, it passes its data onto another object to complete its task. Like in example to my IM application. The login screen would be a class and then it would pass itself on to the buddylist class. Here is a simple example where a greeting is created and defined as "Hello World!". Once the class is through with it, it is passed on to the Leave class where it is manipulated once again.

(Toggle Plain Text)

public class Greet
{
	string hw;    

	public void Greet()
	{
		hw = "Hello World!";
	}

	public string GetVar()
	{
		 return hw;
	}

	public void HelloWorld()
	{
		 Console.WriteLine(hw);
	}
}

public class MainClass
{
	public static void Main()
	{
		Greet g = new Greet();
		g.HelloWorld();
		Leave l = new Leave( g.GetVar() );
		l.GoodbyeWorld();
	}
}

public class Leave
{
	string gw;
   
	public void Leave(string s)
	{
		gw = s;
		//manipulate data and such
		gw = "Goodbye World!";
	}

	public void GoodbyeWorld()
	{
		Console.WriteLine(gw);
	}
}

Also, could you guys provide insight to how YOU go about programming. With OOP there are just so many ways to do it. Is there a "standard" way to use objects and such? I'm throwing out some ideas to see what people think.

DaWei · Feb 16th, 2006, 7:34 AM

OOP? Same as carburetors, CD players, forks, and knives. Some things need to be procedural: mowing the lawn and sweeping the sidewalk. Inhale all the academic theory you like, but keep your bullshit filter turned up high.

Feb 15th, 2006, 1:21 AM	#1
Darkhack Hobbyist Programmer Join Date: Dec 2005 Location: Kansas City Posts: 105 Rep Power: 3	OOP Theory - MI of Objects You'll probebly see me making a million threads like this, lol. I love talking theory. I dont have a lot of expierence with seeing other peoples code so I don't know how things are done by others. Anyways, I was wondering if this theory is acceptable to most programmers. Is it good/bad practice to create all of your objects and then allow them to be used by every other object? I know that sounds confusing. Look below for an example... As you can see I define my objects in advanced and then inherit all of my classes on the main one. That way I can call all of my objects from inside the objects themselves. I actually found this to be pretty easy in some cases. Although I question whether it is acceptable among other programmers. Although this is good in theory, it may prove a little difficult to manipulate it if you had more than instance of a class because of the issues involving which object to manipulate, but if you are careful, I am sure you could work around it. Although if you are only using one instance of a class, it certainly saves you the time of having to pass the objects as parameters and then return them. (Toggle Plain Text) // MAIN public class MainClass { public SubClass obj1; public AnotherClass obj2; public static void Main() { obj1 = new Subclass(); obj2 = new AnotherClass(); obj1.Display(); // <-- basically the same as obj2.Output(); } } // MAIN public class MainClass { public SubClass obj1; public AnotherClass obj2; public static void Main() { obj1 = new Subclass(); obj2 = new AnotherClass(); obj1.Display(); // <-- basically the same as obj2.Output(); } } (Toggle Plain Text) // SubClass + AnotherClass public class SubClass : MainClass { public void Display() { obj2.Output(); } } public class AnotherClass : MainClass { public void Output() { Console.WriteLine("I'm AnotherClass being called from SubClass!!!"); } } // SubClass + AnotherClass public class SubClass : MainClass { public void Display() { obj2.Output(); } } public class AnotherClass : MainClass { public void Output() { Console.WriteLine("I'm AnotherClass being called from SubClass!!!"); } }

Feb 16th, 2006, 6:43 AM	#4
Darkhack Hobbyist Programmer Join Date: Dec 2005 Location: Kansas City Posts: 105 Rep Power: 3	How about treating class as "steps"? You build a framework to use and once that is complete the actual action of the program is completed in steps on higher level classes. Once an object is done doing what it was designed to do, it passes its data onto another object to complete its task. Like in example to my IM application. The login screen would be a class and then it would pass itself on to the buddylist class. Here is a simple example where a greeting is created and defined as "Hello World!". Once the class is through with it, it is passed on to the Leave class where it is manipulated once again. (Toggle Plain Text) public class Greet { string hw; public void Greet() { hw = "Hello World!"; } public string GetVar() { return hw; } public void HelloWorld() { Console.WriteLine(hw); } } public class MainClass { public static void Main() { Greet g = new Greet(); g.HelloWorld(); Leave l = new Leave( g.GetVar() ); l.GoodbyeWorld(); } } public class Leave { string gw; public void Leave(string s) { gw = s; //manipulate data and such gw = "Goodbye World!"; } public void GoodbyeWorld() { Console.WriteLine(gw); } } public class Greet { string hw; public void Greet() { hw = "Hello World!"; } public string GetVar() { return hw; } public void HelloWorld() { Console.WriteLine(hw); } } public class MainClass { public static void Main() { Greet g = new Greet(); g.HelloWorld(); Leave l = new Leave( g.GetVar() ); l.GoodbyeWorld(); } } public class Leave { string gw; public void Leave(string s) { gw = s; //manipulate data and such gw = "Goodbye World!"; } public void GoodbyeWorld() { Console.WriteLine(gw); } } Also, could you guys provide insight to how YOU go about programming. With OOP there are just so many ways to do it. Is there a "standard" way to use objects and such? I'm throwing out some ideas to see what people think.

Feb 16th, 2006, 7:34 AM	#5
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	OOP? Same as carburetors, CD players, forks, and knives. Some things need to be procedural: mowing the lawn and sweeping the sidewalk. Inhale all the academic theory you like, but keep your bullshit filter turned up high. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Thread Tools
Show Printable Version Email this Page
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode

Feb 15th, 2006, 1:48 AM	#2
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,223 Rep Power: 5	What you're doing is essentially making everything have a common base class. A side effect of that is that it is very easy to accidentally introduce coupling you don't want between your classes. The more serious one is that it introduces a phenomenon known as the fragile base class which is a maintenance nightmare in large programs: among other things, it eliminates any potential for separate compilation as (if one thing changes) it is almost certainly necessary to rebuild everything. Do it with a moderate size project (eg a few hundred or a few thousand classes) and you will find you have build times, even when you make minor changes to a line or two, that are quite long. You will also find that is is more difficult to understand how your program works, which makes it difficult to work out where to introduce a new function if you need to.

Feb 15th, 2006, 5:25 AM	#3
Arevos Programming Guru Join Date: Aug 2005 Location: England Posts: 1,499 Rep Power: 5	Grumpy's quite correct. I'll also mention that Singletons come in useful when you absolutely need to only have one instance of a class.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > Other Programming Languages

OOP Theory - MI of Objects