I can't create a clear picture of implementing OOP concepts, though I understand most of the OOP concepts. Why? [closed]

Question

I have been working on some of the projects of my own and dont have any indrustial exposure. Currently i use simple approach for developing small applications with negligible OO approach like creating a common class for database functions using polymorphism of functions little bit use of constructors but i dont really able to think of how to implement whole project logic using OOP.

I know what are interface, abstract class, sealed classes and other oops concepts and very much clear picture in mind. But problem is that when and how should i implement OOP heavily where I should.

Do i need to study real time applications and their case studies, if so please refer me some sites or books/e-books from where i can read them and can be able to implement them.

Currently i feel myself incomplete while programming. I implement database and most of its components effeciently, but a kid while trying to use OOP.

I have read many examples that tries to make one understand OOP like shape eg, car eg. all these kind of. They r gud to clear concepts but not enough to implement in some live project

Answer 1

The first step in learning to apply OOP is to gather common funcitonality and data into classes. You will not do a great job at first, but you will get better. A recent article in Code Magazine about getting back to basics expresses this well.

Start attempting to make (classes that will become) real objects that represent real things in your solution. (There a fancy name for this, but it's also very basic.) This is NOT making utility classes of handy, thematically related functions. Try to arrange things so that the data maintained in your objects saves you parameters when calling methods on that object. Think of the objects that will exists as real individual things in a community. Personify them. Arrange things so that you're not worried about what's going on in the classes while you're using their functionality.

I would not worry about all these design patterns at first. Better to first practice the basic OOP concepts that you have learned. Focusing on these patterns causes a lot of people to skip really thinking about the philosophy of OOP and instead try to jam their situation into a pre-packaged plan. Read about "design patterns" for entertainment and ideas. Later, you'll want to really study them and attempt to specifically implement some of them.

In short, you have to jump in and start applying what you have learned. You need to make some poor designs before you make some good ones, so don't worry about it.

Edit in response to comment from questioner: I think the next step might be to concentrate on the relationships between your classes. Once you are using a Customer object in your logic, for example, you should have to spend No Effort getting the related Order object. Make a property oCustomer.Orders, that returns List<Order>. (This is a c# example.) In this property get all that customer's orders, put them in list object, maintain it in a private variable in case the property is called again, and return that list object. If you have already done this, look for the next hardest new thing to try. Perhaps you need to often find the date a customer first made an order. Then, create an Orders class that inherits from Collection<order> to replace your basic List<order>, and add the property FirstOrder. You can then do var FirstOrderDate = oCustomer.Orders.FirstOrder.OrderDate.

Keep trying to do the next hardest new thing. Inherit and add members. Make a base class with child classes. Override base class members. Use and get good with custom collections.

Learn from the object models you are using. When you see something intuitive and easy to use, do like that! Early in my career I had to extensively use the MS-word object model, which was intuitive and easy. When I made my own libraries, I tried to duplicate that feel; the results were good.

Eventually study the patterns. As much as I advise that you not be over-awed by them, they are a great source of ideas and most importantly stuff to try out. (Knowing the names of common "patterns" is good for communication purposes also.) For example, when you see the plug-in model, the concept of interfaces will really make sense.