Some days ago me and ![[info]](http://stat.livejournal.com/img/userinfo.gif){kind=small}
bpfurtado were talking about different areas of interest on software development and the distance created by programmers in not involving themselves on another interesting (for me :-)) areas, such as process management, requirement analysis, change control processes, etcetera.
Programmers tend to create a barrier between their tasks and other areas on software development, they prefer to be more specialist. Most of them don’t like to participate on requirement analysis discussions, design sessions, development of test cases. They prefer to code instead of being involved on such activities.
When you work on a software development company, you must have interest at the *big thing*, you need to have the whole vision of your area. People around will put better eyes on you, if you show these interest.
Nowadays at my company I’m participating in activies like use case requirement analysis and programming, because I wanna be involved in the best of both worlds. I wanna increase my analysis and programming skills. It was my decision to participate part time on requirement analysis and the rest on programming activities. I think it’s very important to have this vision and consequently it makes you a better professional. And you? Dou you like to be involved not only in programming tasks?
Posts Tagged design
Why not design patterns?
Sep 4
Some months ago, Cedric has reported people criticizing the use of design patterns on software projects, with some arguments like:
- “it’s a sign that your language is fundamentally broken”
- “focus on simpler solutions before going straight to a complex recipe of design patterns”
and other funny things also. Moreover, some said design patterns was inspired in Cristopher Alexander’s Pattern Language book, although design patterns leverage complexity to the programming languages, totally opposed to the Alexander’s book simplicity proposal. As Cedric said, people do criticize, but not provide better solutions. It’s inside our personality: we often try to find defects in all the ways people realize things, but we don’t like to search for better ways to realize the same things. In my opinion, design patterns are:
- Patterns for developing object-oriented reusable software;
- Leverage a solution to a general design problem in a particular context;
- Promotes design reuse;
- Promotes a common vocabulary on the software development team;
- Facilitate software modifications, documentation;
- Promotes manutenable, understandable, legible code, abstracting aspects of a domain problem;
and some other benefits…
So, what do people want? Every time, every software project implementing the same feature in a different way? Of course we’re not saying here to insulate a lot of patterns in a sofware project, but, come on, why not establish a common vocabulary of software instead of doing things all diferent every time? Why reinventing the wheel?
GRASP patterns
Aug 6
Have you ever been told about GRASP patterns? Those kind of patterns are part of the design discipline of the unified process. Their goal is to assign classes responsabilities around the system. We can say GRASP patterns help objects and theirs collaborators to apply the correct behavior as well. I think the most important GRASP patterns are:
- Specialist: put the responsability in the class with the specific knowledge. For instance, in a monetary system, as the account has the information of the balance value, the withdraw() method has to be put in this class.
- Creator: helps deciding who creates the object. If there is an association, aggregation or composition relationships, put in the composed object the responsability to create the other object.
- High Cohesion: classes have only and exact one responsability around the system. Presentation classes don’t have to know persistence classes. It’s a measure of affinity and overloading responsabilities within classes. For instance, in the same monetary system, the Account class only withdraw() money and not saves this information in a persistence mechanism, a collaborator can do this for the account object.
- Low coupling: measures classes dependencies within its context. Classes don’t have to be very dependent on its context. For example, if I have to change my database design, I have to change my business objects also.
- Controller: objects responsible to handle assynchronous event messages originated from GUI. Those can be the use case representation, a system or a subsystem, etcetera… They have the responsability to coordinate tasks and interactions between business objects.
Do you apply GRASP patterns on your software designs? To know more GRASP patterns, checkout this.
Good API design rule
Jul 27
From butUncleBob.com:
“It’s not enough to write tests for an API you develop, you have to write unit tests for code that uses your API.”