Interview Full Stack (edit)
Object-Oriented Programming (OOP)
The four principles of object-oriented programming are encapsulation, abstraction, inheritance, and polymorphism
Concepts & Principles of ...
- Repository pattern
- Unit of work pattern
- Dispose pattern & IDisposable pattern
- Model-View-Controller (MVC) Pattern
- Model-View-Presenter (MVP) Pattern
- Model View ViewModel (MVVM) Pattern
- Service Locator Pattern
- Trusted Facade Pattern
Design Patterns for Microservices
- Independent, autonomous
- Decentralized governance
- Failure isolation
- Continuous delivery through DevOps
Implement the Microservice application layer using the Web API
.NET Best Practices: Architecture & Design Patterns
From GoF-patterns listed there, I came up with this list of Design Patterns in Entity Framework:
- Factory Method, an Entity Framework ObjectContext provides a CreateObjectSet<T> method, which creates an ObjectSet<T> for the given type. Since those object-sets are the main approach to access the entities within a context, I would say it is also a very important pattern used in EF.
- Proxy, obviously EF dynamically creates proxy-types for your entities (unless you tell it not to, or it can't create a proxy because a class is sealed or does not qualify as a "proxyable" type).
- Decorator, this might be a bit far fetched, but to implement lazy-loading in proxy-types, the property-getters of navigation-properties are overloaded, to perform the lazy-loading until requested. This is handled in the proxy type, but also depends on whether lazy-loading is enabled and the navigation-property itself.
- Interpreter, EF introduced Entity-SQL which is a somewhat generalized form of SQL that also has knowledge of the object-orientied entities. You can define a those queries as strings which are then interpreted by EF and turned into provider-dependend SQL.
- Strategy, looking at the various overloads of the ObjectContext.SaveChanges method, you can select from different strategies that are used to determine changes made on known entities.
- Memento, the ObjectStateManager keeps track of changes made to the entities and can be used to access those information including the original-values.
- Facade, exposing entity-sets as IQueryable should qualify as "a simplified interface to a large body of code", since turning such expressions into Entity SQL and than provider-specific SQL is a big deal.
- Observer, ObjectContext provides two eventy ObjectMaterialized and SavingChanges. Since .NET events are an implementation of the observer-pattern, EF also qualifies for this one.
I may have been very generous with naming patterns here, but with some digging you can find a lot of places where EF actually implements those patterns. But since the book is out for nearly 20 years, you can expect that some of these patterns are considered a standard, which isn't worth mentioning. For example the Observer pattern or the Iterator pattern (which I haven't mentioned, just because IQueryable implements IEnumerable).
The Most Important Design Patterns
The singleton pattern is used to limit creation of a class to only one object. This is beneficial when one (and only one) object is needed to coordinate actions across the system. There are several examples of where only a single instance of a class should exist, including caches, thread pools, and registries.
It’s trivial to initiate an object of a class — but how do we ensure that only one object ever gets created? The answer is to make the constructor ‘private’ to the class we intend to define as a singleton. That way, only the members of the class can access the private constructor and no one else.
Important consideration: It’s possible to subclass a singleton by making the constructor protected instead of private. This might be suitable under some circumstances. One approach taken in these scenarios is to create a register of singletons of the subclasses and the getInstance method can take in a parameter or use an environment variable to return the desired singleton. The registry then maintains a mapping of string names to singleton objects, which can be accessed as needed.
2. Factory Method
A normal factory produces goods; a software factory produces objects. And not just that — it does so without specifying the exact class of the object to be created. To accomplish this, objects are created by calling a factory method instead of calling a constructor.
Usually, object creation in Java takes place like so:
SomeClass someClassObject = new SomeClass();
The problem with the above approach is that the code using the SomeClass’s object, suddenly now becomes dependent on the concrete implementation of SomeClass. There’s nothing wrong with using new to create objects but it comes with the baggage of tightly coupling our code to the concrete implementation class, which can occasionally be problematic.
The strategy pattern allows grouping related algorithms under an abstraction, which allows switching out one algorithm or policy for another without modifying the client. Instead of directly implementing a single algorithm, the code receives runtime instructions specifying which of the group of algorithms to run.
This pattern is a one-to-many dependency between objects so that when one object changes state, all its dependents are notified. This is typically done by calling one of their methods.
For the sake of simplicity, think about what happens when you follow someone on Twitter. You are essentially asking Twitter to send you (the observer) tweet updates of the person (the subject) you followed. The pattern consists of two actors, the observer who is interested in the updates and the subject who generates the updates.
A subject can have many observers and is a one to many relationship. However, an observer is free to subscribe to updates from other subjects too. You can subscribe to news feed from a Facebook page, which would be the subject and whenever the page has a new post, the subscriber would see the new post.
Key consideration: In case of many subjects and few observers, if each subject stores its observers separately, it’ll increase the storage costs as some subjects will be storing the same observer multiple times.
As the name implies, a builder pattern is used to build objects. Sometimes, the objects we create can be complex, made up of several sub-objects or require an elaborate construction process. The exercise of creating complex types can be simplified by using the builder pattern. A composite or an aggregate object is what a builder generally builds.
Key consideration: The builder pattern might seem similar to the ‘abstract factory’ pattern but one difference is that the builder pattern creates an object step by step whereas the abstract factory pattern returns the object in one go.
This allows incompatible classes to work together by converting the interface of one class into another. Think of it as a sort of translator: when two heads of states who don’t speak a common language meet, usually an interpreter sits between the two and translates the conversation, thus enabling communication.
If you have two applications, with one spitting out output as XML with the other requiring JSON input, then you’ll need an adapter between the two to make them work seamlessly.
The state pattern encapsulates the various states a machine can be in, and allows an object to alter its behavior when its internal state changes. The machine or the context, as it is called in pattern-speak, can have actions taken on it that propel it into different states. Without the use of the pattern, the code becomes inflexible and littered with if-else conditionals.
Design Pattern provides low-level solutions related to implementation, of commonly occurring object-oriented problems. In other words, design pattern suggests a specific implementation for the specific object-oriented programming problem. For example, if you want to create a class that can only have one object at a time, then you can use the Singleton design pattern which suggests the best way to create a class that can only have one object.
Design Principles provide high level guidelines to design better software applications. They do not provide implementation guidelines and are not bound to any programming language. The SOLID (SRP, OCP, LSP, ISP, DIP) principles are one of the most popular sets of design principles.
- SOLID Design Principles
- Separation of concerns
- Dependency Injection & Inversion of Control
- KISS (Keep It Simple, Stupid)
- TDD (Test Driven Development)
- Model-View-Controller (MVC)
- Dependency Inversion: Đây là một nguyên lý để thiết kế và viết code.
- Inversion of Control: Đây là một design pattern được tạo ra để code có thể tuân thủ nguyên lý Dependency Inversion. Có nhiều cách hiện thực pattern này: ServiceLocator, Event, Delegate, … Dependency Injection là một trong các cách đó.
- Dependency Injection: Đây là một cách để hiện thực Inversion of Control Pattern (Có thể coi nó là một design pattern riêng cũng được). Các module phụ thuộc (dependency) sẽ được inject vào module cấp cao.
SOLID Design Principles
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion
Mechanism & Methodology
Architecture & Architect
Concepts and principles of object oriented programming
What are the advantages and drawbacks of using ...
What are the advantages and disadvantages of using ...
Difference between A and B?
Best practices for ...
HTML: Hyper Text Markup Language
CSS: Cascading Style Sheets
XML: Extensible Markup Language
XMLHttpRequest & Document Object Model (DOM)
JSON is a syntax for storing and exchanging data.
RxJS: RxJS is a library for composing asynchronous and event-based programs by using observable sequences.
ORM: Object-Relational Mapping (ORM)
Entity Framework (ˈɛntɪtɪ) (ˈfreɪmˌwɜːk)
LINQ: Language Integrated Query
- LINQ to Objects: IEnumerable<T>, List<T>, Array, or Dictionary<TKey,TValue>
- LINQ to SQL: IQueryable<T>
- LINQ to Entities: ObjectQuery<T>
- LINQ to XML: XElement &
IEnumerable<T>, List<T>, Array, or Dictionary<TKey,TValue>
ObjectQuery<T> and IQueryable<T>
// Load the XML file from our project directory containing the purchase orders
var filename = "PurchaseOrder.xml";
var currentDirectory = Directory.GetCurrentDirectory();
var purchaseOrderFilepath = Path.Combine(currentDirectory, filename);
XElement purchaseOrder = XElement.Load(purchaseOrderFilepath);
IEnumerable<XElement> pricesByPartNos = from item in purchaseOrder.Descendants("Item")
where (int) item.Element("Quantity") * (decimal) item.Element("USPrice") > 100
IEnumerable<XElement> pricesByPartNos = purchaseOrder.Descendants("Item")
.Where(item => (int)item.Element("Quantity") * (decimal)item.Element("USPrice") > 100)
.OrderBy(order => order.Element("PartNumber"));
Page Life Cycle In ASP.NET
ASP.NET MVC Life Cycle and Application Events
ASP.NET MVC 5
https://www.dotnetcurry.com/aspnet/1494/aspnet-history-part-3-core (ASP.NET Core MVC 6)
WCF: WCF stands for Windows Communication Foundation
Web API: ASP.NET Web API is a framework which allows you to build HTTP services for browsers and mobile devices. It is an ideal platform for developing RESTful applications on the ASP .NET Framework.
SOAP: Simple Object Access Protocol
WSDL: Web Service Definition Language
RESTful: Representational State Transfer (REST)
HTTP status code:
- 200 — OK — Everything is working
- 304 — Not Modified — The client can use cached data
- 400 — Bad Request — The request was invalid or cannot be served. The exact error should be explained in the error payload. E.g. "The JSON is not valid"
- 401 — Unauthorized — The request requires an user authentication
- 403 — Forbidden — The server understood the request, but is refusing it or the access is not allowed.
- 404 — Not found — There is no resource behind the URI.
- 422 — Unprocessable Entity — Should be used if the server cannot process the enitity, e.g. if an image cannot be formatted or mandatory fields are missing in the payload.
- 500 — Internal Server Error — API developers should avoid this error. If an error occurs in the global catch blog, the stracktrace should be logged and not returned as response.
API (Application Programming Interface)
REST (REpresentational State Transfer)
- 200 OK – Trả về thành công cho những phương thức GET, PUT, PATCH hoặc DELETE.
- 201 Created – Trả về khi một Resouce vừa được tạo thành công.
- 204 No Content – Trả về khi Resource xoá thành công.
- 304 Not Modified – Client có thể sử dụng dữ liệu cache.
- 400 Bad Request – Request không hợp lệ
- 401 Unauthorized – Request cần có auth.
- 403 Forbidden – bị từ chối không cho phép.
- 404 Not Found – Không tìm thấy resource từ URI
- 405 Method Not Allowed – Phương thức không cho phép với user hiện tại.
- 410 Gone – Resource không còn tồn tại, Version cũ đã không còn hỗ trợ.
- 415 Unsupported Media Type – Không hỗ trợ kiểu Resource này.
- 422 Unprocessable Entity – Dữ liệu không được xác thực
- 429 Too Many Requests – Request bị từ chối do bị giới hạn
Microsoft’s OWIN (Open Web Interface for .NET)
Dấu hiệu của thiết kế tồi (Poor Design)
Làm cách nào để chúng ta biết được thiết kế phần mềm của mình là tốt? Chương đầu tiên của phần này sẽ liệt kê ra dấu hiệu của thiết kế tồi. Trong chương này, chúng tôi sẽ mô tả những dấu hiệu đó trong một dự án phần mềm và cách phòng tránh nó.
- Tính cứng nhắc (Rigidity) - Thiết kế khó thay đổi.
- Tính bất ổn, dễ vỡ (Fragility) - Thiết kế dễ bị phá vỡ.
- Tính kém lưu động (Immobility) - Thiết kế khó tái sử dụng.
- Tính nhớt (Viscosity) - Khó để làm những điều đúng.
- Sự phức tạp một cách không cần thiết (Needless Complexity) - Thiết kế quá phức tạp.
- Sự lặp đi lặp lại một cách không cần thiết (Needless Repetetion) - Lạm dụng chuột quá nhiều (Ý là dùng chuột copy paste quá nhiều).
- Tính mờ đục (Opacity) - Sử lý ngoại lệ không được tổ chức rõ ràng.
Nguyên tắc thiết kế (Design Principles)
Nguyên tắc thiết kế trong lập trình hướng đối tượng giúp các lập trình viên phòng trách các thiết kế tồi và đưa ra thiết kế tốt nhất cho các đặc trưng của hệ thống:
- SRP - Nguyên tắc về một trách nhiệm --- Single Responsibility Principle
- OCP - Nguyên tắc đóng mở --- Open-Closed Principle
- LSP - Nguyên tắc thay thế Liskov --- The Liskov Substitution Principle
- DIP - Nguyên tắc đảo ngược sự phụ thuộc --- Dependency Inversion Principle
- ISP - Nguyên tắc tách biệt các lớp --- Interface Segregation Principle