OOP Best Practices

[cyberbobcity]

I have an app I created for my company a few years ago that I'd like to redesign not only with some nice web 2.0 stuff but also make the structure as "perfect" as possible.

I know right now there are current problems with the way work with classes. I have a piece of code that defines and instantiates one of every one of my classes, so I don't have to instantiate it every time I use it. This seems to be causing problems on very rare occasions since multiple people are using it. It just seems to be a pain instantiating my user class everytime i need it... what do i do?

other things that don't seem right is when I need to retrieve a combined set of properties from multiple objects to display in a table on a web site. Since for instance I want a list of users and the client name of that user. The client name is in the client class. So I basically just create a function in the user class saying GetUsersList() and it does a sql query bringing back all the fields I want, including the client name. It just seems off.

So basically my questions are:

1. What is a good reference on OOP design in a real world setting, not on polymorphism and inheritance, but how classes interact and are actually used.

2. Are there any good examples of realworld apps with very perfect coding.

3. What is the best way to get a list of a combined set of properties from multiple objects.

4. Are there best practices for instantiating classes globally instead of locally?
Thanks for any help you can give me.

 

[DonQuichote]

1. What is a good reference on OOP design in a real world setting, not on polymorphism and inheritance, but how classes interact and are actually used.

I think the notion of "Design by Contract" is a good one on interaction. The term was coined up by Bertrand Meyer, the father of the Eiffel language. In thinking of contracts, I cannot help to think of code modules or classes as people, departments or organizations, since they have responsibility in real life.

For instance, you could have a "user shop" that provides you with a user object. How that user object was instantiated or where it came from, is then the responsibility of the shop. Your shop can cache it (to prevent multiple instances of the same user or just to save on database traffic). And your shop can subcontract the instantiation to another class or library.

In the same fashion, you can have a "client shop" that provides client objects.

2. Are there any good examples of realworld apps with very perfect coding.

Not that I know of. When I think a piece of code is "as good as it can get", it is in for maintenance a month later. "Good" is only subjective. Like there is no best car. Your best car may be a truck if you want to transport a lot, a family van if you want to go on holiday, a tiny car if you want to park in the city, or whatever you think makes a car "good". It is the same with code. As "good" is often defined by "what the customer wants tomorrow", it is advisable to just write the simplest thing that could possibly work and not to add anything that might be needed later. Add that functionality when it IS needed.

3. What is the best way to get a list of a combined set of properties from multiple objects.

Make an object responsible for it. Really. You can define a TableRow object that gets access to your central piece of instantiation and gets passed the selection criteria needed to get the necessary objects out of the shops.

4. Are there best practices for instantiating classes globally instead of locally?

Not really. Objects have interfaces. Do not be confused with the interface keyword in many languages. That defines a partial interface. The interface of an object consists of everything that can be called from outside. You can compare this with the connectors of an electronic device, like a hard disk. Hard disks have more than one connector: a power consuming one, a data channel, and a blinking-led-connector. These plugs are recognisable and separate. Like partial interfaces you define with the "interface" keyword.
Now what happens if something does not go through the interface? If then becomes hardwired to the hard disk. If the ground line would not be connected through the power plug, it would be soldered to the electronics of the hard disk itself. In electronics, you can SEE that it is bad: it directly breaks all modularity and clarity, and violates contracts.

It is the same in object-oriented programming: if you access objects that were (directly or indirectly) not passed through the interface, you open a big can of worms. You tie that class to the stealthily called code and have no control over it.

But do not think in global versus local. EVERY object has its scope. An Application object may have (indirect) access to all your instances, and a shop only to its own members. It is not uncommon to create objects that just provide access to others. The Application object is a famous example, but you can also use a Backend object for access to your persistent objects, or a UI object to have a central point of acces for any piece of user-interface code.

In fact, trying to make objects really global removes that scope and therefore control over it. If you use a Singleton (anti-)pattern, for example, you never know when the instance gets created, and you cannot pass it data needed for construction. You also cannot know when it gets cleaned up. And both construction and cleaning up usually require things to be done in the right order.

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[jmeckley]

check out the book Domain Driven Design by Evans. this is a great resource for application development. Another book which I see mentioned alot, but have not read is Enterprise Architecture.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[noodle22]

I found Head First Design Patterns to be a really good book as well. It uses these examples that are really basic and has tons of stupid tricks/jokes to make the book fun to read and help you remember when to use stuff. There is also a Head First OO Design book which I would not recommend after glancing through it but the design patterns one is truely great for understanding when to use inheritance, polymorphism, etc.

http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124

 

[lespaul]

I just had a Eureka moment in OOP and Java with the Head First Java book (see thread678-1485417) I'm planning on reading more of them too!

Leslie

Have you met Hardy Heron?