Interfaces are recognized as an important mechanism to define contracts governing interactions between semi-independent software modules. Well-designed interfaces significantly reduce software complexity and ease maintainability by fostering modularization, hiding implementation details and minimizing the impact caused by changes in the software implementation. However, designing good interfaces is not a trivial task. The presence of interface design defects often yield increased development cost, lower code quality and reduced development productivity. Despite their importance, currently there are only a few research efforts that investigate the quality of interface design. In this paper, we identify and characterize common interface design anomalies and illustrate them via examples taken from well-known open source applications. In order to quantify the presence of interface design anomalies and estimate their impact on the interface design quality, as well on the software quality attributes, such as maintainability, we conduct an empirical study covering 9 open source projects. Building on our empirical results, we develop a set of recommendations to improve interface design.
On the other hand, Fowler and Beck @cite_11 propose a set of bad smells in OO class design: . They also propose refactorings for improving code quality with respect to the type of code smell. Based on Fowler and Beck's definitions of class smells, several approaches to automatically improving code quality have been developed. Murno proposes an approach based on code smells to automatically identify design smells and where to apply refactorings in a Software application @cite_21 . Trifu and Marinescu establish a clear distinction between OO structural problems and code smells, and present a causal approach to restructuring OO applications @cite_10 . Liu al @cite_12 provide a deep analysis of the relationships among different kinds of bad smells and their influence on resolution sequences.
@cite_21 @cite_10 @cite_12 @cite_11
2149963636 2532677196 2097987957 2153887189
Refactoring can have a direct influence on reducing the cost of software maintenance through changing the internal structure of the source-code to improve the overall design that helps the present and future programmers evolve and understand a system. Bad smells are a set of design problems with refactoring identified as a solution. Locating these bad smells has been described as more a human intuition than an exact science. This paper addresses the issue of identifying the characteristics of a bad smell through the use of a set of software metrics. Then by using a pre-defined set of interpretation rules to interpret the software metric results applied to Java source-code, the software engineer can be provided with significant guidance as to the location of bad smells. These issues are addressed in a number of ways. Firstly, a precise definition of bad smells is given from the informal descriptions given by the originators Fowler and Beck. The characteristics of the bad smells have been used to define a set of measurements and interpretation rules for a subset of the bad smells. A prototype tool has been implemented to enable the evaluation of the interpretation rules in two case studies. Software decay is a phenomenon that plagues aging software systems. While in recent years, there has been significant progress in the area of automatic detection of "code smells" on one hand, and code refactorings on the other hand, we claim that existing restructuring practices are seriously hampered by their symptomatic and informal (non-repeatable) nature. This paper makes a clear distinction between structural problems and structural symptoms (also known as code smells), and presents a novel, causal approach to restructuring object oriented systems. Our approach is based on two innovations: the encapsulation of correlations of symptoms and additional contextual information into higher-level design problems, and the univocal, explicit mapping of problems to unique refactoring solutions. Due to its explicit, repeatable nature, the approach shows high potential for increased levels of automation in the restructuring process, and consequently a decrease in maintenance costs. Bad smells are signs of potential problems in code. Detecting and resolving bad smells, however, remain time-consuming for software engineers despite proposals on bad smell detection and refactoring tools. Numerous bad smells have been recognized, yet the sequences in which the detection and resolution of different kinds of bad smells are performed are rarely discussed because software engineers do not know how to optimize sequences or determine the benefits of an optimal sequence. To this end, we propose a detection and resolution sequence for different kinds of bad smells to simplify their detection and resolution. We highlight the necessity of managing bad smell resolution sequences with a motivating example, and recommend a suitable sequence for commonly occurring bad smells. We evaluate this recommendation on two nontrivial open source applications, and the evaluation results suggest that a significant reduction in effort ranging from 17.64 to 20 percent can be achieved when bad smells are detected and resolved using the proposed sequence. Almost every expert in Object-Oriented Development stresses the importance of iterative development. As you proceed with the iterative development, you need to add function to the existing code base. If you are really lucky that code base is structured just right to support the new function while still preserving its design integrity. Of course most of the time we are not lucky, the code does not quite fit what we want to do. You could just add the function on top of the code base. But soon this leads to applying patch upon patch making your system more complex than it needs to be. This complexity leads to bugs, and cripples your productivity.