What is a good gauge for knowing when a class is poorly designed or even necessary. In other words when to write a class and when no to.
SOLID might help if a class is poorly designed, but it won't help answer a question like "Is object-oriented programming the best approach for this problem?"
People have done a lot of very good work in programming for mathematics and science before object-oriented programming came into vogue. If your problem falls into those categories, perhaps object-oriented programming isn't for you.
Objects are state and behavior together; they tend to map onto problem domain objects one-to-one. If that's not true for your problem, perhaps object-oriented programming isn't for you.
If you don't know an object-oriented language well, perhaps object-oriented programming isn't for you.
If your organization doesn't know and can't support object-oriented solutions, perhaps object-oriented programming isn't for you.
A lot of people will say the "SOLID Principles" are a good guideline for class design.
There are a lot of articles/podcasts concerning the SOLID Principles, just do a quick search. Here's a good start:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
rather than list a bunch of don't-do-this rules for recognizing a poorly-designed class, it is easier - and more efficient - to list the few rules governing a good class design:
a class is a collection of related state and behavior
the behavior should use only the state and method parameters
if you think about the state as a relation (i.e. as the columns in a relational database table), the object ID (pointer) is the primary (synthetic) key and the state comprises the non-key attributes. Is the object in third normal form? If not, split it into two or more objects.
is the lifecycle of the object complete? In other words, do you have enough methods to take the object from creation through use and finally to destruction/disposal? If not, what methods (or states/transitions) are missing?
is all of the state used by at least one method? If not, does it provide descriptive information useful to a user of the object? If the answer to both of these is no, then get rid of the extraneous state.
if the problem you're trying to solve requires no state, you don't need an object.
On top of the SOLID principles, have a look at Code Smells. They were mentioned first (IIRC) in Martin Fowler's "Refactoring" book, which is an excellent read.
Code smells generally apply to OO and also procedural development to some degree, including things like "Shotgun Surgery" where edits are required all over the codebase to change one small thing, or "Switch Case Smell" where giant switch cases control the flow of your app.
The best thing about Refactoring (book) is that it recommends ways to fix code smells and takes a pragmatic view about them - they are just like real smells - you can live with some of them, but not with others.
Related
Recently, i go back to read some parts of the "UML Reference Manual" book, second edition (obviously by: Booch, Rumbaugh, Jacobson).
(see: http://www.amazon.com/Unified-Modeling-Language-Reference-Manual/dp/020130998X)
Meanwhile, i have found these "strange" words in the first chapiter "UML overview" at "Complexity of UML" section:
There is far too much use of generalization at the expense of essential distinctions. The myth that inheritance is always good has been a curse of object orientation from earliest days.
I can't see how this sentence can be fully in line with Object Oriented Paradigm which states that inheritance is a fundamental principle.
Any idea/help please?
You seem to believe the two points are mutually exclusive. They are not. Inheritance is a fundamental and powerful principle of object-oriented programming, and it is overused.
It is overused typically by inexperienced developers who are so captivated with the idea of inheritance that they are more focused on the inheritance tree than solving the problem. They try to factor out as much code as possible to some parent base class so they can just reuse it throughout the tree, and as a result they have a brittle design.
One of the greatest evils of software engineering is tight coupling between classes. That's the sort of thing that causes you to have to work through the weekend after the customer asks for a simple change. Why? Because making a change in one class has an effect on another class, and fixing that class has an effect on another, and so on.
Well, there is no tighter coupling than inheritance.
When you factor too much out to the "top level," every derived class is coupled to it. And as you find more and more code you want to factor out to various levels, you eventually have these deep trees, and every change made at the top cascades throughout the tree. As a result, you start to have methods that return null or are empty. They're unnecessary for the class, but the inheritance contract demands they be there. This violates the Liskov Substitution Principle.
So use inheritance of course. But do it smartly. Favor delegation to inheritance if you have any doubt. And when you do use inheritance, make sure you aren't factoring commonalities to the top level (of the whole tree or a subtree) just to reuse common code, but rather do so because there is a commonality of behavior from top to bottom.
If your tree is more than two or three levels deep (and I think three is really pushing it), you are almost certainly setting yourself up for trouble.
Everything is good in moderation. Remember that the quote is not saying do not use it, or avoid, etc. Rather it is saying it is an overused principal when other OO abstractions or principals work better. Inheritance is powerful but it's coupling is tight.
Wisely or rather randomly the author of the UML book is saying pointing out this current truism that inheritance is often over-used and over-referenced. What about all the other principals and abstractions. I find that developers typically only hit the OO highlights (inheritance being one) and use that abstraction to excess.
For me in UML it is a good reminder that UML is OO generally, but it is not limited to Java or .Net OO features. Many languages only offer of the abstractions available across all languages. UML attempts to help you model and express many of them.
Remember the author only said 'too much use', not bad or incorrect. Also remember that maybe you are an expert developer who does not apply inheritance incorrectly.
I have a question related to general OOP than specific to a language.
I was trying out a simple application (in java) and I was trying to model it like a real world scenario.
While re-factoring I realized that I came up with a simple object that just has one member and an overridden equals and hashcode.
My question is.... is it a bad oo practice to have such objects
(references to blogs etc would be welcome)
Short answer:
is it a bad oo practice to have such objects
Not necessarily, but it depends on the context.
Longer answer:
I have a question related to general OOP than specific to a language. I was trying out a simple application (in java) and I was trying to model it like a real world scenario.
There really isn't any rule stating that you should. In fact, I know of quite a few people who frown upon that statement, Uncle Bob Martin for one. It's more about modelling business processes than it is to model "real world scenarios". I've tried that in the past, and found there's no - or almost no - benefit to get from rigidly trying to model everything as it is in the real world. If anything, I think it makes your application more complex, and the more complex software becomes, the harder it becomes to maintain.
While re-factoring I realized that I came up with a simple object that just has one member and an overridden equals and hashcode.
Might be okay, as #Arseny already said, the ValueObject is a well-known way of working, although I usually don't end up with a lot of them when I write code. If more than a few of your objects doesn't have any behaviour, this might be an indication of a so-called Anemic Domain Model, which you have to be careful for (more complexity at no apparent benefit).
You can find out if you're "doing it wrong" (with variable values of "wrong", of course): just see what the collaborators are doing with your ValueObject, and see if there's anything there that resembles a calculation which actually belongs to the object itself.
However, if this is one of the few objects that doesn't contain any behaviour: well, yeah, that happens and you probably don't have to worry about it. We'd have to see some code to be conclusive in our anwers though.
For this case, no, because that's the only way to redefine the behavior of an object in a hashing data structure in Java.
For other cases there may be better and worse methods of doing things depending on whether they make sense, for example, if I want to change the order of objects in a queue, I'd prefer to implement a custom Comparator rather than inherit and override a compareTo method, especially if my new comparison routine is not "natural" for the objects.
Every design pattern has some cases that it's appropriate for and others that it's inappropriate for.
Normally, it would be considered a smell to have an object with no behaviour. The reason being that if it doesn't have any behaviour, then it isn't an object. When desiging your class you should be asking things like, "what is the class responsible for?". If it doesn't have any behaviour then this is a difficult questions to answer.
Rare exceptions to this being something like the Null Object pattern.
http://en.wikipedia.org/wiki/Null_Object_pattern
I may be that the member of your class should actually be a member of another class.
It may also be that your class has some functionality that you haven't discovered yet.
It may also be that you are putting too much importance on the concept when a primitive type would do.
There are a number of techniques for designing OO systems, here is one of the original:
http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card
No it is not bad. There is Value Object pattern witch widely used and DTO pattern as well.
I 'm concern about what techniques should I use to choose the right object in OOP
Is there any must-read book about OOP in terms of how to choose objects?
Best,
Just write something that gets the job done, even if it's ugly, then refactor continuously:
eliminate duplicate code (don't repeat yourself)
increase cohesion
reduce coupling
But:
don't over-engineer; keep it simple
don't write stuff you ain't gonna need
It's not a precise recipe, just some general guidelines. Keep practicing.
P.S.
Code objects are not related to tangible real-life objects; they are just constructs that hold related information together.
Don't believe what the Java books/schools teach about objects; they're lying.
You probably mean "the right class", rather than "the right object". :-)
There are a few techniques, such as text analysis (a.k.a. underlining the nouns) and Class Responsibility Collaborator (CRC).
With "underlining the nouns", you basically start with a written, natural language (i.e. plain English) description of the problem you want to solve and underline the nouns. That gives you a list of candidate classes. You will need to perform several passes to refine it into a list of classes to implement.
For CRC, check out the Wikipedia.
I suggest The OPEN Toolbox of Techniques for full reference.
Hope it helps.
I am assuming that there is understanding of what is sctruct, type, class, set, state, alphabet, scalar and vector and relationship.
Object is a noun, method is a verb. Object members can represent identity, state or scalar value per field. Relationships between objects usually are represented with references, where references are members of objects. In cases, when relationships are complex, multidirectional, have arity greater than 2, represent some sort of grouping or containment, then relationships can be expressed as objects.
For other, broader technical reasons objects are most likely the only way to represent any form of information in OOP languages.
I am adding a second answer due to demian's comment:
Sometimes the class is so obvious
because it's tangible, but other times
the concept of object it's to abstract
like a db connector.
That is true. My preferred approach is to perform a behavioural analysis of the system (using use cases, for example), and then derive system operations. Once you have a stable list of system operations (such as PrintDocument, SaveDocument, SpellCheck, MergeMail, etc. for a word processor) you need to assign each of them to a class. If you have developed a list of candidate classes with some of the techniques that I mentioned earlier, you will be able to allocate some of the operations. But some will remain unallocated. These will signal the need of more abstract or unintuitive classes, which you will need to make up, using your good judgment.
The whole method is documented in a white paper at www.openmetis.com.
You should check out Domain-Driven Design, by Eric Evans. It provides very useful concepts in thinking about the objects in your model, what their function are in the domain, and how they could be organized to work together. It's not a cookbook, and probably not a beginner book - but then, I read it at different stages of my career, and every time I found something valuable in it...
(source: domaindrivendesign.org)
I've read all the books about why to create a class and things like "look for the nouns in your requirements" but it doesn't seem to be enough. My classes seem to me to be messy. I would like to know if there are some sort of metrics or something that I can compare my classes to and see if there well designed. If not, who is the most respected OO guru where I can get the proper class design tips?
Creating classes that start clean and then get messy is a core part of OO, that's when you refactor. Many devs try to jump to the perfect class design from the get go, in my experience that's just not possible, instead you stumble around, solving the problem and then refactor. You can harvest, base classes and interfaces as the design emerges.
if you're familiar with database design, specifically the concept of normalization, then the answer is easy: a data-centric class should represent an entity in third normal form
if that is not helpful, try this instead:
a class is a collection of data elements and the methods that operate on them
a class should have a singular responsibility, i.e. it should represent one thing in your model; if it represents more than one thing then it should be more than one class.
all of the data elements in a class should be logically associated/related to each other; if they aren't, split it into two or more classes
all of the methods in a class should operate only on their input parameters and the class's data elements - see the Law of Demeter
that's about as far as i can go with general abstract advice (without writing a long essay); you might post one of your classes for critique if you need specific advice
Try to focus on behaviour instead of structure. Objects are 'living' entities with behaviour and responsibilities. You tell them to do things. Have a look at the CRC-card approach to help you model this way.
i think Object design is as much art as it is science. It takes time and practice to understand how to design clean & elegant classes. Perhaps if you can give an example of a simple class you've designed that you aren't happy with SO users can critique and give pointers. I'm not sure there are any general answers outside of what you've already read in the texts.
The most respected OO guru i personally know is StackOverflow. Put your classnames here and i reckon you'll get a goodly number of reviews.
Classes are typically used to model concepts of the problem domain. Once you have a well-defined problem (aka the set of use cases), you will be able to identify all participants. A subset of the participants will be intrinsic to the system you are designing. Start with one big black box as your system. Keep breaking it down, as and when you have more information. When you have a level where they can no longer be broken down (into concepts in your problem domain), you start getting your classes.
But then, this is a subjective view of a non-guru. I'd suggest a pinch of salt to the menu.
Metrics? Not so's that you'd trust them.
Are your classes doing the job of getting the program working and keeping it maintainable through multiple revisions?
If yes, you're doing ok.
If no, ask yourself why not, and then change what isn't working.
I've lately been thinking a lot about alternatives to the class-based approach to object-orientation.
One thing which bugs me in today's languages is that we often use static classes / singletons to design single (global) objects because there isn't any other way to do it, so in my opinion it's rather a hack than a feature.
Another thing is that Java for instance allows the programmer to have enums with additional data (global state) and functionality which make them kind of object in my eyes, too.
Anyway, what I'd like to know is whether you have any ideas for a different approach to object-orientation in a compiled and efficient language (therefore, creating objects by prototyping is probably not a good idea) or, if you don't have any, whether there're things in the classic OO approach which bug you a lot, too.
[EDIT]:
Just to make things clear. As indicated above I already know prototype-based programming.
Check out prototype-based programming.
Take a look at the Actor Model. It's something like classes except for being asynchronous. If each actor is a Finite-State-Machine, you would have a potentially powerful system.
Erlang uses something like that, I'm told... at least similar. The point with the actor model is that it doesn't need to be implemented purely, and so does not need to be part of Erlang.
I started a small language that used that model once a few years ago. I might try it again sometime.
Now that my flame retardent suit is safely secured, I can say it: I dislike OOP.
The central problem I have with it is that it tries to come up with a single taxonomy in which every unit of functionality truly belongs.
There are a couple of problems with this. First, producing a good taxonmy is hard. People suck at creating them. Secondly, I am not convinced that you can actually structure a sensible, maintainable, hierarchy that will withstand change in a project containing a lot of entities; the whole practice of refactoring is basically acknowledging the difficulty of creating large, all incompassing taxanomies.
Actually, I think that OOP is over-engineered. Everything you can do with OOP can be done with higher-order functions (HOFs). HOFs are much more elegant, much more flexible solution to the same problems that OOP tries to address.
So if you're asking of another way to do OOP style stuff, HOFs are probably the closest alternative technology that has a similiar level of flexibility.
I think you are having trouble defining the "classical OO" approach. Is the signal method in Objective-C classical or the static method in standard C++?
In functional languages, it's easy enough to have non-object functions that, in a sense, act like objects because they return functions whose implementations are opaque. For example, the following code in Scheme
(define (create-ball color)
(lambda (attribute-name)
(if (equal? attribute-name "color")
color
"method-not-supported"))))
will output a function which isn't officially an "object" but it can act like one since it stores state, but you're not very clear about what exactly is wrong with the object-oriented paradigms you have been exposed to.
take a deep look at javascript which has the prototype based model or check out lua which has a some strange way to implement object orientation
Take a look at CLOS, which is basically function/method based.
Google's Go language takes a decidedly different approach to object orientation, maybe worth a look.