reading-notes

Code Fellows 201

Domain modeling is the process of creating a conceptual model in code for a specific problem. A model describes the various entities, their attributes and behaviors, as well as the constraints that govern the problem domain. An entity that stores data in properties and encapsulates behaviors in methods is commonly referred to as an object-oriented model.
A domain model that’s articulated well can verify and validate the understanding of a specific problem among various stakeholders. As a communication tool, it defines a vocabulary that can be used within and between both technical and business teams.

The main reasons are as follows:

Layout tables reduce accessibility for visually impaired users: screen readers, used by blind people, interpret the tags that exist in an HTML page and read out the contents to the user. Because tables are not the right tool for layout, and the markup is more complex than with CSS layout techniques, the screen readers’ output will be confusing to their users.
Tables produce tag soup: As mentioned above, table layouts generally involve more complex markup structures than proper layout techniques. This can result in the code being harder to write, maintain, and debug.
Tables are not automatically responsive: When you use proper layout containers (such as <header>, <section>, <article>, or <div>), their width defaults to 100% of their parent element. Tables on the other hand are sized according to their content by default, so extra measures are needed to get table layout styling to effectively work across a variety of devices.

Table Header: <th> special cells that go at the start of a row or column and define the type of data that row or column contains (as an example, see the “Person” and “Age” cells in the first example shown in this article).
Table Rows: <tr> To stop a row from growing and start placing subsequent cells on a second row, we need to use the <tr> element (‘tr’ stands for ‘table row’).
Table Data: <td> The smallest container inside a table is a table cell, which is created by a <td> element

Using object literals is fine when you only need to create one object, but if you have to create more than one, as in the previous section, they’re seriously inadequate. We have to write out the same code for every object we create, and if we want to change some properties of the object - like adding a height property - then we have to remember to update every object.
We would like a way to define the “shape” of an object — the set of methods and the properties it can have — and then create as many objects as we like, just updating the values for the properties that are different.

This. isn’t hugely useful when you are writing out object literals by hand, but it will be essential when we start using constructors to create more than one object from a single object definition Object Prototypes Using A Constructor

NOTE: This is a very common front end developer interview question

Prototypes are the second place to look for a function; a conmputer will check the properties first then move to prototypes (like a stunt double doing the hard work)