design-pattern-java | 设计模式 Java版本 | Architecture library

Bridge is splitting the interface and implementation in multiple parts. In your example you'll get 2 different interfaces Shape, Color. They will generate their own class hierarchies and because they are independent they can both vary.

You'll end up with multiple shapes and multiple colors that can be combined at runtime. This is achieved using composition instead of inheritance. Each instance of a Shape needs an instance of a Color when it gets created and that's the way you get a red triangle or a green pentagon or any other combination of a Shape and a Color.

The hierarchies aren't tightly coupled and they only communicate at an interface level.

Short answer: Yes. It's just code.

Long answer: No, that's not how MVC is designed. MVC is specifically designed to separate the logic from the view. In fact, in .NET the data layer is normally a completely separate class library that's just referenced by the frontend. The server and the client are designed to be separate, to keep the backend and the frontend away from each other.

I know the following you probably know already, but I'd just like to reiterate and clarify: MVC stands for Model, View, Controller (obviously), but this is what each does:

Model: The Model can be thought of as your average class. It contains a structure and functions relating to a specific object, as well as the CRUD for the model (most of the time the actual model and the CRUD are also separated, but very closely linked and related). The Model is what your application uses to understand how to communicate, calculate, and construct.

View: The View is what the client sees. It is the actual web page, the actual front end. Ideally (although impractically), it contains no logic whatsoever. Most of the time there is SOME logic here (mostly JavaScript logic, sometimes server logic can be embedded here too to create a dynamic user experience). This is where your HTML, CSS, and (client side) JavaScript lives.

Controller: This is the liaison between the Model and the View. It takes a request from the client, sends it to the Model, which then returns a constructed model. The Controller then performs any necessary calculations, and passes the model to the view. The Controller essentially described the Model to the View - it explains how entities interact and relate with each other.

Think of it this way: I have a model called ApplicationUser and a CRUD class called ApplicationUserCRUD. A client logs onto my site (View Layer), which sends a request to my Controller. The Controller takes their request (in this case, let's say the request is their username and password), and passes it to the CRUD (Controller Layer). The CRUD then checks whether or not the user exists, and if the password matches (Model Layer). Then, when it's confirmed, it sends the information to the Model. The Model then returns to the Controller, which passes it to the View in order to construct the View.

If you are trying to perform logic and calculations in your Model, you're not using MVC properly. Logic and calculations are performed in the Controller, SOMETIMES the View, and in some cases a Helper class.

A Helper class is a Controller that doesn't relate to a specific Area/View.

Also, the CRUD is normally called the DAL, or Data-Access-Layer. It's yet another layer that essentially sits parallel with the Model Layer, but contains the logic for interacting with the server/database. I mention this in order to demonstrate how much people dislike adding logic to the Model - so much so that they create an entirely new layer just to hold the logic.

Hope this helped!