Die Suche ergab 448 Treffer

von eichberg
23. Nov 2017 13:42
Forum: Software Engineering - Design and Construction
Thema: Behavior of getClass() vs instanceof in equals()
Antworten: 1
Zugriffe: 171

Re: Behavior of getClass() vs instanceof in equals()

If a class is effectively final (i.e., it is not possible to write subclasses of it) and all superclasses of it are abstract (or are interfaces) then it doesn't matter.
von eichberg
21. Nov 2017 17:04
Forum: Software Engineering - Design and Construction
Thema: Exercise 4 - Extensions for the library?
Antworten: 1
Zugriffe: 226

Re: Exercise 4 - Extensions for the library?

Users of the library are not expected to implement classes in the "lib" package.
von eichberg
21. Nov 2017 13:03
Forum: Software Engineering - Design and Construction
Thema: Ex 4.1 non-null parameters
Antworten: 6
Zugriffe: 934

Re: Ex 4.1 non-null parameters

In general a contract that is defined w.r.t. a returned value, is a contract that has to be satisfied by the implementation of the method. If a parameter has to have a certain value/does not have to be null then this contract has to be satisfied by the caller. Given that null-checks are basically c...
von eichberg
20. Nov 2017 09:59
Forum: Software Engineering - Design and Construction
Thema: Immobile classes vs tight coupled classes
Antworten: 2
Zugriffe: 328

Re: Immobile classes vs tight coupled classes

Both things are related: in general, if the coupling between classes becomes tighter the less mobile these classes are. However, it may be the case that we have (a few) tightly coupled classes which are also conceptually tightly related. This set (as a whole) can be considered to be mobile if the in...
von eichberg
20. Nov 2017 09:23
Forum: Software Engineering - Design and Construction
Thema: Differences between ISP and LSP
Antworten: 1
Zugriffe: 721

Re: Differences between ISP and LSP

1. So for ISP it always refers to interfaces, and LSP for concrete classes? ISP is about "bloated" interfaces (here, interfaces is not the same as Java interface, but interfaces in general) that define too much functionality and should be split up. LSP is about violations of the behavior defined by...
von eichberg
17. Nov 2017 13:48
Forum: Software Engineering - Design and Construction
Thema: Ex 3.1
Antworten: 3
Zugriffe: 320

Re: Ex 3.1

The reason why I'm asking is that if we list every class that is just immobile because it depends on one immobile class, this would bloat the list a lot and make fixing it harder. A class that depends on an immobile class should be considered as immobile too. Whether the fix is easy/easier is – for...
von eichberg
17. Nov 2017 08:53
Forum: Software Engineering - Design and Construction
Thema: Ex 3.1
Antworten: 3
Zugriffe: 320

Re: Ex 3.1

You should annotate the package as such and list all immobile classes there.

In package-info.scala

Code: Alles auswählen

@Immobile({
   xyz.class,
   uvw.class
})
@Rigid({
   abc.class,
   def.class
})
package ex03.lib;
von eichberg
17. Nov 2017 08:41
Forum: Software Engineering - Design and Construction
Thema: Ex 3.1.2: Rigidity
Antworten: 3
Zugriffe: 359

Re: Ex 3.1.2: Rigidity

In this case, mark A as being rigid.
von eichberg
17. Nov 2017 08:38
Forum: Software Engineering - Design and Construction
Thema: Ex 3.3 - fields
Antworten: 5
Zugriffe: 505

Re: Ex 3.3 - fields

A member which (based on its type) has a direct dependency to a concrete (unstable) class is generally a DiP violation. However, the constructor is not a problem pre-se; the potential problem is the call of the constructor. Hence, a perfectly DIP compliant solution would just use dependency injectio...
von eichberg
16. Nov 2017 10:10
Forum: Software Engineering - Design and Construction
Thema: Exercise 3 - Task 3 DIP - for which files?
Antworten: 1
Zugriffe: 251

Re: Exercise 3 - Task 3 DIP - for which files?

You are right: for all methods of all classes in the lib package - but not for the inner classes.
von eichberg
16. Nov 2017 10:06
Forum: Software Engineering - Design and Construction
Thema: Ex 3.3 - fields
Antworten: 5
Zugriffe: 505

Re: Ex 3.3 - fields

As said in the lecture: when we think about the DIP, we are generally concerned about dependencies on low-level implementation classes (which are not stable). Stable classes such as String are not of any concern. Furthermore, it is irrelevant whether the field is final and/or private or not; you hav...
von eichberg
16. Nov 2017 09:51
Forum: Software Engineering - Design and Construction
Thema: Ex 3.4: Toplevel interfaces
Antworten: 2
Zugriffe: 255

Re: Ex 3.4: Toplevel interfaces

You should focus on the three named classes.

(We do not consider the concrete classes such as Map or Stack as defining a (relevant) top-level interface.)
von eichberg
16. Nov 2017 09:48
Forum: Software Engineering - Design and Construction
Thema: Ex 3.1.2: Rigidity
Antworten: 3
Zugriffe: 359

Re: Ex 3.1.2: Rigidity

A design (regarding a set of classes and their interactions) is rigid if a change - here in the exercise we are particular concerned about: an extension - forces many changes upon the existing code base (i.e., other classes need to be changed). Hence, consider some extension scenarios to identify th...
von eichberg
15. Nov 2017 14:56
Forum: Software Engineering - Design and Construction
Thema: Exercise 03 Understanding of Lib package
Antworten: 1
Zugriffe: 253

Re: Exercise 03 Understanding of Lib package

This definitively makes more sense. Thanks for pointing out.

(However, please recall that this class is only intended to demonstrate how the library could be used - you are not required to assess the quality of the code in the app package.)
von eichberg
13. Nov 2017 10:51
Forum: Software Engineering - Design and Construction
Thema: Ex02 - Generic return type
Antworten: 4
Zugriffe: 329

Re: Ex02 - Generic return type

The line:

Code: Alles auswählen

int test = Context.get("test", () -> Context.getNextId());
is the same (at runtime/in Bytecode) as the following:

Code: Alles auswählen

int test = Context.get("test", () -> Context.getNextId()).intValue();;
The intValue call is automatically added by the compiler

Zur erweiterten Suche