This course extends object-oriented analysis and design by incorporating design patterns to create interactive applications. Through a survey of established design patterns, you will gain a foundation for more complex software applications. Finally, you will identify problematic software designs by referencing a catalog of code smells. You will be challenged in the Capstone Project to redesign an existing Java-based Android application to implement a combination of design patterns. You will also critique a given Java codebase for code smells. After completing this course, you will be able to: • Demonstrate how to use design patterns to address user interface design issues. • Identify the most suitable design pattern to address a given application design problem. • Apply design principles (e.g., open-closed, dependency inversion, least knowledge). • Critique code by identifying and refactoring anti-patterns. • Apply the model-view-controller architectural pattern.
2.3.2 – Open/Closed Principle
Loading...
來自 University of Alberta 的課程
Design Patterns
338 個評分
從本節課中
Working with Design Patterns & Anti-patterns
You will learn a design pattern that is very useful for user interfaces: model-view-controller, or MVC. Then you will learn some principles underlying the design patterns, to create software that is flexible, reusable, and maintainable. Finally, you will learn some of the symptoms of bad design, which we call code smells or antipatterns.
與講師見面
Kenny WongAssociate Professor
Computing Science, Faculty of Science
As a software developer,
you should strive to create systems that are flexible and reusable.
Flexible code bases allow for easier extension of the system.
Reusable code, means that you don't need to
reimplement something that's already been done.
Achieving both of these goals will help to make your code more maintainable.
The design patterns that you've learned during this course are all
different techniques you can use to help you write flexible and reusable code.
They are a means through which you can improve the quality of your code.
All design patterns follow a basic set of design principles,
which address issues such as flexibility, and reusability.
One of these principles is called the Open/Closed Principle.
This principle states, that classes should be open for extension,
but closed to change.
Now, what does that mean?
As the name of this principle suggests,
there are two parts to it, open or closed.
Let's examine what each part means.
You should consider a class as being "closed" to editing,
once it has been tested to be functioning properly.
The class should be behaving as you would expect it to behave.
All the attributes and behaviors are encapsulated,
and proven to be stable within your system.
The class, or any instance of the class should not stop your system from running,
or do any harm to it.
The closed portion of the principle doesn't mean that you can't go
back to a class to make changes to it during development.
It's expected for things to change during
the design and analysis phase of your development cycle.
Changes to your classes are expected at that stage.
Once you've reached a point in development where you've
already finalized most of your design decisions,
and have implemented most of your system,
then you should consider closing your classes.
During the lifetime of your software,
certain classes should be closed,
to avoid introducing undesirable side effects.
Of course, you should still fix a closed class if there are any bugs,
or unexpected behaviors occurring.
So, what do you do if you need to add more features?
How do you extend your systems?
This is where the open part of the design principle comes in.
There are two different views of the open part of the principle.
But they both view a class to be open if you can still build upon it.
There are two different ways to extend your system using the open principle.
The first way, is through Inheritance of a superclass.
The idea is that, when you want to add
more attributes and behaviors to a class that is considered closed,
you can simply use inheritance to extend it.
This way, your subclasses will still have all the original functions of the superclass.
But now you can add extra features in the subclasses.
This helps preserve the integrity of the superclass,
so that if you don't need the extra fluff of the subclasses,
you still have the original class to use.
Remember that subclasses can also be extended,
so you can use the Open/Closed Principle to
continually extend your system as much as you want.
You may reach a point where you no longer want a class to be extendable,
in which case you can declare a class to be final,
which will prevent further inheritance.
The keyword "final" can also be used on methods.
The second way I class can be considered open to extension,
is if the class is abstract and enforces the Open/Closed Principle through polymorphism.
An abstract class can declare abstract methods with just the method signatures.
Each concrete subclass must provide their own implementation of these methods.
The methods in the abstract superclass are preserved,
and you can extend your system by providing different implementations for each method.
This can be useful for behaviors that can be accomplished in different ways,
like sorting and searching.
You can also use an interface to enable polymorphism.
But keep in mind that with an interface,
you won't be able to define a common set of attributes.
The Open/Closed Principle is used to keep
the stable parts of your system separate from the varying parts.
Well, you want to be able to add more features to your system.
You don't want to do it at the expense of disrupting something that works.
By using extension over change,
you can work on the varying parts without
introducing unwanted side effects into the stable parts.
Varying parts of a system should be kept isolated from each other.
Since these extensions will eventually become
stable and become integrated into your production,
there's no guarantee that they'll all be completed at the same time.
Some features and behaviors may be more complex than others.
Some may be larger, and more ambitious,
or some may be discarded completely,
due to time or financial considerations.
Isolating varying subsystems from each other can also
prevent unwanted side effects from occurring when you're implementing them.
All design patterns use the Open/Closed Principle in some form.
They all follow the idea that some part of your system should be able to extend,
and to be built upon through some means,
like inheritance, or implementing an interface.
The Open/Closed Principle is a concept that,
helps keep a system stable,
by closing classes to changes,
and allows the system to open for
extension through the use of inheritance, or interfaces.
It may not always be possible to practice this principle,
but it's something you should strive for.
Having a reliable, and robust system is something you want to have.
You want to build featureful systems,
but you also want them to have good performance.
A flexible, and reusable code base plays a key part in providing that.
Design Patterns are used to address specific software problems.
But they all rely on a set of unifying ideas.
The Open/Closed Principle is one of those ideas that is used by design patterns.
And is also a principle you should use when designing,
and building your software solutions.
