Die aktuelle Diskussion um geringe Bildungschancen von Kindern sozial benachteiligter Familien beweist, dass Kinder Nachteile gegenüber ihren Altergenossen haben, wenn man sie nicht fördert. Komplexleistungen zur Frühförderung sollen dieses Risiko eindämmen.
Two schools of thought underpin the way OO programming languages support encapsulation.Object encapsulation ensures that private members are accessible only within a single object.Class encapsulation allows private members to be accessed by other objects of the same class.This paper describes an empirical investigation into the way encapsulation is used in practice in class encapsulation languages C# and Java.We find arbitrary and inconsistent programming practices and suggest that object encapsulation is more intuitive and provides OO design advantages.
Industrial-scale software is commonly very large and complex, making it difficult and time-consuming to develop. In order to manage complexity in software, developers break systems into smaller components which can be developed independently. Software contracts were first proposed several decades ago; they are used to explicitly specify the interfaces between software components to ensure that they work together correctly. Software contracts specify both the responsibility of a client using a service and of the component providing the service. The advantage of contracts is that they formalise what constitutes correct interactions between software components. In addition, they serve as documentation, as well as a basis for test cases, and help clarify correct use of inheritance. However, despite their usefulness, software contracts are still not widely used in mainstream software engineering. In this work, we aim to develop a new software contract tool which we hope will help increase the use of software contracts. We start our work by evaluating existing software contract technologies and uncover a range of inconsistencies and shortcomings. We find that there are disagreements surrounding even some of the most basic aspects of software contracts. Using the lessons learned from our analysis of existing tools, we design a new contract tool, PACT. We describe in detail the formal semantics and typing of PACT and develop a first implementation of our tool. Finally, we discuss the advantages of PACT over existing tools, including its rigorous separation of interfaces and implementations, its rich inheritance semantics, and its support for flexible and expressive definition of contracts.
Object-oriented programming languages allow multiple variables to refer to the same object, a situation known as aliasing. Aliasing is a powerful tool which enables sharing of objects across a system. However, it can cause serious encapsulation breaches if not controlled properly; through aliasing, internal parts of aggregate objects can be exposed and potentially modified by any part of the system. A number of schemes for controlling aliasing have been proposed, including Clarke et al.’s ownership types and Boyland et al.’s capabilities. However, many existing systems lack flexibility and expressiveness, making it difficult in practice to program common idioms or patterns which rely on sharing, such as iterators. We introduce aliasing contracts, a dynamic alias protection scheme which is highly flexible and expressive. Aliasing contracts allow developers to express assumptions about which parts of a system can access particular objects. Aliasing contracts attempt to be a universal approach to alias protection; they can be used to encode various existing schemes.